How to get file creation time (Ext4, ntfs-3g)?

isync · 06-14-2010, 04:02 PM

I know newer filesystems support crtime values, even to nanoseconds granularity. Ext4 does it, and NTFS mounted via ntfs-3g should expose it. Still, what is the command to get these values??

getfattr -d <some file>

gives me zero results, and as far as I know ls does not have means to access creation time.

getfattr -n ntfs_crtime /mnt/<some ntfs fs> gives me "Operation not opermitted"..?

I know about the difference between ctime=inode change time and crtime=creation time/file birth time.
I want to migrate a NTFS partition to Ext4 without losing the creation dates...

PTrenholme · 06-14-2010, 07:04 PM

The getfattr command returns extended file attributes - things like SELinux settings. Look at the -c option of the ls command to expose file creation times. For example:

Code:

[Peter ~]$ ls -lc /Vista/boot/
total 1016
-rwxrwxrwx. 1 root root  28672 Apr  6 16:57 bcd
-rwxrwxrwx. 1 root root 262144 Apr  6 16:57 BCD.LOG
-rwxrwxrwx. 2 root root 262144 Dec 19 03:51 BCD.LOG1
-rwxrwxrwx. 2 root root      0 Dec 19 03:51 BCD.LOG2
-rwxrwxrwx. 1 root root   1024 Dec 19 03:51 bootfix.bin
-rwxrwxrwx. 1 root root  65536 Dec 19 03:51 bootstat.dat
[Peter ~]$ ls -lc Scripts/tmp
total 8
-rwxr-xr-x. 1 Peter Peter 673 Jun  7 17:27 scramble
-rwxr-xr-x. 1 Peter Peter 821 Jun  7 17:27 scramble~

syg00 · 06-14-2010, 08:35 PM

That's not crtime - even on ext4.
The crtime is maintained (in ext4), but I don't think there is a (convenient) means of extracting it (yet). If you get a files inode (say 9999), you can do this against the filesystem itself (include the < >)

Code:

debugfs -R 'stat <9999>' /dev/sda?

isync · 06-16-2010, 09:07 AM

@PTrenholme: as syg00 sais: that's change time (ctime), not crtime!

@syg00: your command worked (and did send the hdd into a second of strange grrrr sounds...). Example output:

Quote:

Inode: 5505072 Type: regular Mode: 0644 Flags: 0x80000
Generation: 3777246081 Version: 0x00000000:00000001
User: 1000 Group: 1000 Size: 65666
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 136
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4c179224:b06523cc -- Tue Jun 15 16:45:56 2010
atime: 0x4c17922d:472056f4 -- Tue Jun 15 16:46:05 2010
mtime: 0x4c17921f:720ab41c -- Tue Jun 15 16:45:51 2010
crtime: 0x4c17921f:303ce20c -- Tue Jun 15 16:45:51 2010
Size of extra inode fields: 28
EXTENTS:
(0-16): 22057124-22057140

And that's the only way to get this? Yes?
(Actually I would need to read out crtime via perl... - ideas?)

PTrenholme · 06-16-2010, 04:24 PM

Quote:

Originally Posted by isync

@PTrenholme: as syg00 said: that's change time (ctime), not crtime!

Oops! My bad!

(Again.) One of these days I need to learn how to read better.

There is a B option in the find command, but -- on my Fedora system using an ext4 system -- I get this:

Code:

$ find ./ -newerBt "yesterday"
find: This system does not provide a way to find the birth time of a file.
find: invalid predicate `-newerBt'

so that's not much help.

The debugfs suggestion works for ext4, but I don't think that it would work for a ntfs file, since the NTFS doesn't actually have an inode. When I tried it, I got this:

Code:

$ ls -i /Vista/Users/
25503 All Users  25504 Default User  63970 Judy  15441 Public
15405 Default    25502 desktop.ini     217 Peter

$ sudo debugfs -R 'stat <217>' /dev/sda3
debugfs 1.41.10 (10-Feb-2009)
/dev/sda3: Bad magic number in super-block while opening filesystem
stat: Filesystem not open

syg00 · 06-16-2010, 05:24 PM

Debugfs is part of e2fsprogs - I wouldn't expect it to work on any other f/s; sorry if I wasn't clear on that. Merely offered to prove the data is there.
There have been rumblings on lkml to get the data out, but it would involve other code changes all over the place.
And occupy more in kernel space - which the devs are dead against anytime.

isync · 06-16-2010, 08:27 PM

Quote:

Originally Posted by PTrenholme

... since the NTFS doesn't actually have an inode. When I tried it, I got this...

I did the same on an ntfs-3g mounted volume and got the same error.

Actually I got the crtime squeezed out of NTFS with a little util called ntfsinfo.
The only problem was that my mounted volume would only be probable with the -f force option, and this marked the NTFS volume as "dirty". Next time I booted the volume under Windows, chkdsk came up...

Very unsatisfying that you can only probe for crtime from Linux on offline/unmounted NTFS volumes...

MTK358 · 06-17-2010, 07:25 AM

Linux filesystems do not store the creation time.

syg00 · 06-17-2010, 07:53 AM

Rubbish. Read the entire thread.

isync · 06-19-2010, 09:36 AM

May I say it again: "Very unsatisfying that you can only probe for crtime from Linux on offline/unmounted NTFS volumes"!!

Any other ideas to do it guys?

syg00 · 06-19-2010, 05:49 PM

NTFS is Microsoft proprietary. It is not a Linux filesystem, nor are its internal released publicly.
You're lucky it's supported at all - maybe you should offer some assistance to the linux-ntfs project to include it rather than moan about it.