Description of problem: stat not showing file's Birth date from the crtime in the file's idnode. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. stat /etc/fstab 2. debugfs -R 'stat <Above_Inode:_value_here>' /dev/sda4 Example: $ stat /etc/fstab File: â/etc/fstabâ Size: 1703 Blocks: 8 IO Block: 4096 regular file Device: 804h/2052d Inode: 1203752 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-20 01:01:01.935654698 -0500 Modify: 2015-02-14 21:46:25.419876021 -0600 Change: 2015-02-14 21:46:25.496876522 -0600 Birth: - <============================================ $ debugfs -R 'stat <1203752>' /dev/sda4 debugfs 1.42.12 (29-Aug-2014) Inode: 1203752 Type: regular Mode: 0644 Flags: 0x80000 Generation: 3660892693 Version: 0x00000000:00000001 User: 0 Group: 0 Size: 1703 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x54e01691:7676efa8 -- Sat Feb 14 21:46:25 2015 atime: 0x550bb79d:df13d4a8 -- Fri Mar 20 01:01:01 2015 mtime: 0x54e01691:641b32d4 -- Sat Feb 14 21:46:25 2015 crtime: 0x54e01691:641b32d4 -- Sat Feb 14 21:46:25 2015 <============ Size of extra inode fields: 28 EXTENTS: (0):4893254 Reproducible: Steps to Reproduce:
Summary: 5b4: stat not showing file's Birth date => 5b3: stat not showing file's Birth date
This is INVALID. POSIX doesn't mandate that filesystems store a creation time attribute, only modify, access, and change times, and most filesystems only support those three attributes. They are a standard part of the inode structure. A filesystem optionally may store other attributes, such as a creation time, in extended file attributes. AFAIK, most filesystems do not do this. (ZFS and ext4 do) Furthermore, stat works (just as ls does when it reads the timestamps) by using the lstat system call, which is universal on UNIX systems. The lstat call contains a pointer to a stat struct in which the results are returned. This struct only contains slots for an atime, mtime, and ctime. Why the stat output has the "Birth" line is beyond me, but the fact that it's not populated is neither new nor unique. It does the same thing on Mageia 4 and Solaris 11, etc. Solaris 11 does have an ls option for viewing it "ls -l -%all filename," but Linux's doesn't have that. It requires ls to use an additional system call to retrieve the extended file attributes. You can take this up with upstream coreutils if you'd like :o)
Status: NEW => RESOLVEDResolution: (none) => INVALID
(In reply to David Walser from comment #1) > Why the stat output has the "Birth" line is beyond me, http://lists.gnu.org/archive/html/coreutils/2011-10/msg00071.html > but the fact that > it's not populated is neither new nor unique. It does the same thing on > Mageia 4 and Solaris 11, etc. > > You can take this up with upstream coreutils if you'd like :o) coreutils was waiting for xstat patch/update in kernel. Found this https://sourceware.org/ml/libc-alpha/2012-04/msg00711.html Should this bug be reopened with source rpm set to kernel or a new bug report or would still be invalid because Mageia is declared as "only POSIX compliant".
It would be invalid because it's not a bug. It's not even an enhancement request in Mageia-land; it is upstream. So if this is ever implemented in the kernel and coreutils, then we'll pick it up once we have the versions of those that make it available. We won't backport it to existing releases.