Bug 15536

Summary: 5b3: stat not showing file's Birth date
Product: Mageia Reporter: Bit Twister <bittwister2>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Normal    
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: coreutils-8.23-5.mga5 CVE:
Status comment:

Description Bit Twister 2015-03-20 14:38:57 CET 
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:
Bit Twister 2015-03-20 18:50:36 CET

Summary: 5b4: stat not showing file's Birth date => 5b3: stat not showing file's Birth date

Comment 1 David Walser 2015-03-20 21:01:12 CET 
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 => RESOLVED
Resolution: (none) => INVALID

Comment 2 Bit Twister 2015-03-20 22:41:31 CET 
(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".
Comment 3 David Walser 2015-03-24 00:55:13 CET 
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.