1

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]#
  • it is not opened. – again Mar 8 '18 at 12:07
  • 2
    You should state which FS you are using... 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. Anything you do which gives a creation time will be meaningless. – Philip Couling Mar 8 '18 at 12:19
  • ext4 does store crtime: see the wiki on kernel.org and the inode.c source. It's stored at offset 0x90 of the inode. See @Stéphane Chazelas's comment. – ErikF Mar 8 '18 at 12:38
4

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.

  • But showing creation time is larger than modification time. – again Mar 8 '18 at 12:54
  • @again. As a said the mtime can be set to any date including dates in the past, prior to the creation time of the file, like with that touch command I gave as an example. – Stéphane Chazelas Mar 8 '18 at 13:01
  • So, you are saying data is ok. but, somehow it changed. – again Mar 8 '18 at 13:10
  • @again, yes something apparently did set the mtime to that 2018-03-07 07:05:15. The fact that the nanosecond part is 0 is an other indication that it was the case. Do you know how those files were created? Were they extracted from archives, were they copied with cp -a, rsync -a, restored from backup... All cases that would set arbitrary mtimes. – Stéphane Chazelas Mar 8 '18 at 13:14
0

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.

  • 2
    His debugfs output indicates that it's ext4 and that crtime is supported. Newer Linux kernels now have an interface to retrieve that crtime, but AFAIK, the userland tools like ls/find/stat, and even the GNU libc have not been adapted yet to use that new API, so one still needs to resort to debugfs to get it straight from the FS. – Stéphane Chazelas Mar 8 '18 at 12:23
  • Thats true... I was taking the OP's comment on face value. – Philip Couling Mar 8 '18 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.