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

Question

For a long time, Linux hasn't bothered with file creation dates because none of the file systems it commonly used supported them. However now, 2 file systems commonly used (NTFS and ext4) both record file creation dates.

The stat command, however, still outputs Birth: - on an ext4 file system, even though we can see that ext4 has stored the file's create date using debugfs -R 'stat <inode_number>' /dev/file_device.

When I looked into why this is, I saw that someone else has already recently filed a bug report on it, and the response links through to an upstream issue that simply states "there is no Linux kernel interface at present to get that info [file creation date]". It seems remarkable to me that this is apparently still the case, as people have been requesting that stat display this info for years (and stat does output a Birth field, even though it apparently doesn't support it yet! Did they add it in anticipation?)

So is it still true that there is no Linux kernel interface at present to get file creation date? Is there a plan to implement this ever?

Answer 1

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.

Answer 2

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.

Answer 3

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).

---

^{¹ as a special case, with ext4, if the file system has been created with an inode size of 128 bytes, the birth time field is not included.}