When is Birth Date for a file actually used?

Question

When I type the following:

$ IFS=$'\n'; arr=( $(stat "/bin/bash") ); for i in ${arr[@]} ; do echo $i ; done
  File: '/bin/bash'
  Size: 1037528     Blocks: 2032       IO Block: 4096   regular file
Device: 823h/2083d  Inode: 656086      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-05-23 16:38:03.848124217 -0600
Modify: 2017-05-16 06:49:55.000000000 -0600
Change: 2017-05-18 07:43:22.946694155 -0600
 Birth: -

I see the Birth Date for /bin/bash is null / empty. When is this field ever used and what purpose might it have in Linux when it works?

I appreciate there is a shorter way of using stat but this came up during development cycle and I copy and pasted.

Solution 1

Birth time is the time when the file was created on the filesystem, also known as the file creation time (crtime on EXTFS). Note that, this is not defined by POSIX; only last access time (atime), last modification time (mtime) and the inode change time (ctime) are mandated by POSIX.

IIRC, Linux yet does not provide any interface for getting the birth time, there is a proposal for xstat() and fxstat(), yet to be implemented.

As @muru noted, the newer approach is statx(), which is merged in the mainline kernel recently. So, any (modified) userspace tool can leverage that (the statx structure now, see below) on any such recent kernel.

struct statx {
    __u32   stx_mask;
    __u32   stx_blksize;
    __u64   stx_attributes;
    __u32   stx_nlink;
    __u32   stx_uid;
    __u32   stx_gid;
    __u16   stx_mode;
    __u16   __spare0[1];
    __u64   stx_ino;
    __u64   stx_size;
    __u64   stx_blocks;
    __u64   __spare1[1];
    struct statx_timestamp  stx_atime;
    struct statx_timestamp  stx_btime;
    struct statx_timestamp  stx_ctime;
    struct statx_timestamp  stx_mtime;
    __u32   stx_rdev_major;
    __u32   stx_rdev_minor;
    __u32   stx_dev_major;
    __u32   stx_dev_minor;
    __u64   __spare2[14];
};

Here stx_btime is the file creation time.

In the meantime, stat is showing absence of the fields (or the empty values) st_birthtime/st_birthtimesec returned by the stat() call, in the stat structure:

struct stat {
   dev_t     st_dev;     /* ID of device containing file */
   ino_t     st_ino;     /* inode number */
   mode_t    st_mode;    /* protection *
   nlink_t   st_nlink;   /* number of hard links */
   uid_t     st_uid;     /* user ID of owner */
   gid_t     st_gid;     /* group ID of owner */
   dev_t     st_rdev;    /* device ID (if special file) */
   off_t     st_size;    /* total size, in bytes */
   blksize_t st_blksize; /* blocksize for filesystem I/O */
   blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
   time_t    st_atime;   /* time of last access */
   time_t    st_mtime;   /* time of last modification */
   time_t    st_ctime;   /* time of last status change */
   };

There are some tricks with filesystem level debugging request to get the creation info from FS metadata e.g. for EXTFS:

debugfs -R 'stat /path/to/file' /dev/sda1

assuming the FS of the file in question is on partition /dev/sda1. You can extract the value of crtime to get the creation time of the file.

Solution 2

It should be the file creation time, but there is an outstanding issue, the gnu coreutils team waiting for xstat() support in the kernel.

TODO: stat(1) and ls(1) support for birth time

Comments

[Eliah Kagan]

Possible duplicate of How do I find the creation time of a file? Particularly useful is muru's answer, which offers a way to access the crtime / birth time, and show like stat will once it actually supports it, on systems whose kernels have the new statx() system call. This doesn't require root privileges. See also Birth is empty on ext4 on Unix & Linux.

[WinEunuuchs2Unix]

@EliahKagan statx has been around for a few months in Linux kernels. People just aren't coding in application space for it yet. It still interests me and I thank you for reminding me of this back-burner project.

[muru]

xstat is ancient history. statx has been merged quite recently.

[Muzer]

Worth pointing out that file creation time isn't often particularly useful as many text editors will save by creating a new file and then overwriting the old one (means you'll never get a partially-saved file if it crashes during saving). On Windows they use some extreme hackery to make this appear to work (except when it doesn't - see blogs.msdn.microsoft.com/oldnewthing/20050715-14/?p=34923 ) but to my knowledge no such thing exists in Linux.

[WinEunuuchs2Unix]

@heemayl As I'm a Linux C noob and can only copy, paste & compile, can you point to a link where a C program "reads" the new mainline kernel data structure and prints it to STDOUT? (Apologies if terminology is off).

[heemayl]

@WinEunuuchs2Unix I don't think the rewritten regular programs that uses statx() instead of stat() is available right now in any mainline such program version...you can check the latest source to be sure that if some program has implemented the interface and then compile teh program or you can always write your own program that leverages statx()... In both cases, i am assuming that you have the required kernel version that exposes statx()...

[WinEunuuchs2Unix]

@heemayl statx() was added in Kernel 4.11 which, I installeda couple weeks ago (version 4.11.1 ). I've rebooted this version and will try to see if someone has posted a sample program to use. If not I'll have to download stat command source code, modify it and recompile it. Thanks for your great answer and hopefully I can post a working copy of new statx program in a week or two :) PS Interesting side note: statx() includes a new field for version number. This is something I was asking questions a couple days ago on how to determine a programs version number.

[heemayl]

@WinEunuuchs2Unix Thats data version number, not program version number in general sense...

[muru]

@WinEunuuchs2Unix it's not enough for you to have the corresponding kernel. Usually, userspace programs use libc to interface with the kernel's system calls. We use glibc, and afaik glibc hasn't added support for statx yet, so there's no simple way to use it directly. Also, statx's version number is probably for filesystems which can keep multiple versions or snapshots of a file, and nothing to do with a command's idea of its version

[WinEunuuchs2Unix]

@muru Thanks for the heads up. Right now I'm stuck at the first step of getting GCC to use the right include directories for header files when compiling 4.11.1 stat.c program anyway. I'm a long way off from runtime libraries. :(