Creation time anomaly

Question

I need to know the creation time of a file. I tried to run the stat filename command. But my fs does not store file creation time as metadata.

[root@s1 XYZ]# stat ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
  File: `./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp'
  Size: 16241           Blocks: 32         IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 129108489   Links: 1
Access: (0644/-rw-r--r--)  Uid: (  509/ UNKNOWN)   Gid: (  509/ UNKNOWN)
Access: 2018-03-07 12:28:31.000000000 +0200
Modify: 2018-03-07 07:04:15.000000000 +0200
Change: 2018-03-07 12:28:31.468075157 +0200

However, I read this site and used debugfs command. It shows crtime (creation time). But the shown creation time is larger (newer) than modification time. What is wrong?

[root@s1 XYZ]# ls -i ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
129108489 ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
[root@s1 XYZ]# df -T ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
Filesystem                Type  1K-blocks       Used Available Use% Mounted on
/dev/mapper/datavg-datalv ext4 5986257120 5645927428  36483732 100% /data
[root@s1 fcs_backup]#  debugfs -R 'stat <129108489>' /dev/mapper/datavg-datalv
debugfs 1.41.12 (17-May-2010)
Inode: 129108489   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 3953510053    Version: 0x00000000:00000001
User:   509   Group:   509   Size: 16241
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 32
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5a9fbecf:6f990a54 -- Wed Mar  7 12:28:31 2018
 atime: 0x5a9fbecf:00000000 -- Wed Mar  7 12:28:31 2018
 mtime: 0x5a9f72cf:00000000 -- Wed Mar  7 07:04:15 2018
crtime: 0x5a9fbecf:6f990a54 -- Wed Mar  7 12:28:31 2018
Size of extra inode fields: 28
EXTENTS:
(0-3): 516503300-516503303

Edited File is not opened. I run through the same way.

[root@s1 XYZ]# stat ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
      File: `./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp'
      Size: 16241           Blocks: 32         IO Block: 4096   regular file
    Device: fd02h/64770d    Inode: 129108489   Links: 1
    Access: (0644/-rw-r--r--)  Uid: (  509/ UNKNOWN)   Gid: (  509/ UNKNOWN)
    Access: 2018-03-07 12:28:31.000000000 +0200
    Modify: 2018-03-07 07:04:15.000000000 +0200
    Change: 2018-03-07 12:28:31.468075157 +0200
    [root@s1 XYZ]#  debugfs -R 'stat <129108489>' /dev/mapper/datavg-datalv
    debugfs 1.41.12 (17-May-2010)
    Inode: 129108489   Type: regular    Mode:  0644   Flags: 0x80000
    Generation: 3953510053    Version: 0x00000000:00000001
    User:   509   Group:   509   Size: 16241
    File ACL: 0    Directory ACL: 0
    Links: 1   Blockcount: 32
    Fragment:  Address: 0    Number: 0    Size: 0
     ctime: 0x5a9fbecf:6f990a54 -- Wed Mar  7 12:28:31 2018
     atime: 0x5a9fbecf:00000000 -- Wed Mar  7 12:28:31 2018
     mtime: 0x5a9f72cf:00000000 -- Wed Mar  7 07:04:15 2018
    crtime: 0x5a9fbecf:6f990a54 -- Wed Mar  7 12:28:31 2018
    Size of extra inode fields: 28
    EXTENTS:
    (0-3): 516503300-516503303
    [root@s1 XYZ]# lsof ./px/cd/78/cd78eholuefekgpz6c0snn5oaayypnloqxgfivszd5d.mxp
    [root@s1 XYZ]#

Answer 1

The ctime and crtime cannot be tampered with, the atime and mtime can be set by user processes to arbitrary values using the utime() or utimes() (or utimensat() for nanosecond precision) system calls like touch typically does or tar when you extract an archive (where it sets the modification time of the file to that as stored in the archive (so typically, in the past)).

You can achieve the same with:

touch -t 201803070704.15 newfile

for instance, where the crtime and ctime would be set to the current time, but the mtime and atime to the specified one.

Answer 2

You should state which FS you are using.

You are trying to get the creation time. But you've stated that

my fs does not stores file creation time as metadata

If that's true then you cannot get the creation time no-matter what you do. If the file system doesn't store it then nothing else will!

Timestamps can be very tricky and don't always mean what you think they mean. For example if you extract a tar or zip archive, the mtime field will be set to whatever timestamp was contained in the archive (some time in the past). But the crtime will reflect the time / date you extracted the archive.

The crtime will not be modified by regular programs so if mtime is changed, crtime will not be.

So even if the crtime is correct, the mtime will often be set to something completely different.