Is there still no Linux kernel interface to get file creation date?

EDIT: Good news, statx() has been merged so it should be available in release 4.11.

  • https://lwn.net/Articles/716302/
  • https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f

xstat() work, currently statx(), was revised in 2016.

  • http://lwn.net/Articles/685791/
  • http://lwn.net/Articles/686106/

The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.


because none of the file systems it commonly used supported them

From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.

See http://www.pathname.com/fhs/pub/fhs-2.3.html

POSIX lays out three time stamps. None of them are creation time.

If I remember correctly the argument went something like:

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.

I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.


The birth time is in several Linux native file systems, not only ext4.

Since version 4.11 of the Linux kernel (April 2017), there's a new statx() system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat, ls, find have not been updated to use it (2019-08-22 edit GNU stat on GNU/Linux systems with glibc 2.28 or above supports it since coreutils 8.31; 2021-01-04 edit and GNU ls has a --time=birth since coreutils 8.32)

You could do it in perl though with something like:

perl -MPOSIX -e '
  require "syscall.ph";
  $buf = "\0" x 0x100; # enough space for a struct statx
  for (@ARGV) {
    # hardcode: AT_FDCWD == -100
    #           AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
    #           STATX_BTIME = 0x800 for the mask
    #           80: offset of the btime in the struct
    syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
      or die "$_: $!\n";
    ($t, $n) = unpack("x80QQ", $buf);
    $n = sprintf("%09d", $n);
    print strftime("%F %T.$n %z\n", localtime $t)
  }' -- "$file"

If your syscall.ph doesn't have SYS_statx, you could hardcode it as well. It's 332 on amd64 architectures. Or try:

printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1

Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).

Tags:

Filesystems

Stat

Recent Posts