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?


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

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

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.

  • The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
    – Jez
    Mar 10 '17 at 16:20
  • @Jez fixed. LWN link will become available 7 days later.
    – sourcejedi
    Mar 10 '17 at 16:44
  • I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
    – shrx
    May 22 '17 at 9:33
  • @shrx: Glibc didn't support xstat until 2.28 so perhaps that was the problem in May 2017? Feb 3 '20 at 9:56

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.

  • 2
    Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
    – coteyr
    Aug 21 '16 at 16:15
  • 1
    using something like debugfs to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
    – ilkkachu
    Aug 21 '16 at 16:36
  • Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :) Apr 24 '18 at 18:16

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

  • If Linux did fully support NFSv4it would need to support extended attributes and there is a possible entry crtime in the extended attributes. Check e.g. the Solaris ls.c source that prints the file creation time with ls -l -% crtime.
    – schily
    Jun 28 '18 at 12:52
  • @schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available through statx(). There's no standard utility which interface to statx() yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume? Jun 28 '18 at 13:04
  • Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened via openat(fd, ".", O_RDONLY|O_XATTR).
    – schily
    Jun 28 '18 at 13:12
  • @schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris. Jun 28 '18 at 13:19
  • @schily, looks like you've added misinformation to Wikipedia on that. Please fix. Jun 28 '18 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.