Eric Blake wrote: > * src/stat.c (print_stat): New %w and %W formats. > (do_stat): Include %w in verbose format. > (usage): Document them. > * doc/coreutils.texi (stat invocation): Likewise. > * NEWS: Likewise. > Suggested by Andre "Osku" Schmidt. > --- > > I've tested that this works on cygwin. On Fedora 13 with an
And on Rawhide+ext4 and RHEL5.5+ext3 > ext4 partition, the birthtime appears to not be returned in > stat(). If the kernel guys will ever commit to a stable > xstat() interface, which we can then write gnulib wrappers Per this summary, http://lwn.net/Articles/397442/ and some lkml traffic, it seems there is hope. > for, we can use that instead. I'm assuming this will also > work on BSD systems, although I have not yet tested that. > > I wasn't sure how to write a test for this - how to tell if > a filesystem has birthtime support exposed by the kernel? > Ideas on that front are welcome. Test it with stat -f %w . ;-) Seriously, neither do I. > For an example of what it looks like on a file system with > all four times: ... > diff --git a/doc/coreutils.texi b/doc/coreutils.texi > index 52f1b20..c5dda4f 100644 > --- a/doc/coreutils.texi > +++ b/doc/coreutils.texi > @@ -10696,6 +10696,8 @@ stat invocation > @item %T - Minor device type in hex > @item %u - User ID of owner > @item %U - User name of owner > +...@item %w - Time of file birth, or @samp{-} if unknown > +...@item %W - Time of last birth as seconds since Epoch, or @samp{-} As I read it, birth time is likely to be unchangeable, so let's omit that "last" (which looks like a vestige more than something deliberate). > @item %x - Time of last access > @item %X - Time of last access as seconds since Epoch > @item %y - Time of last modification ... > + %x Time of file birth, or - if unknown\n\ > + %X Time of file birth as seconds since Epoch, or - if unknown\n\ > %x Time of last access\n\ > %X Time of last access as seconds since Epoch\n\ > %y Time of last modification\n\ As Pádraig mentioned, s/%x/%w/ and s/%X/%W/ Regarding whether to print " Birth: -" in the default output when no information is available, I have a slight preference to print it. First, it should be fine, since no one should be parsing that default output, so we can change it without fear of breaking client scripts. Second, seeing that empty line there may encourage users and developers of lagging file systems and/or kernels to add support (yeah, right).
