How can get the creation date of a file?

Question

I want to find out the creation date of a particular file on a Linux system. Not the modification date or access date, the creation date.

I have tried with ls -ltrh and stat filename but neither gives me what I need. What else can I do to get this information?

Answer 1

stat -c '%w' file or ls -l --full-time --time=birth on filesystems that store creation time.

Note that on Linux this requires coreutils 8.31, glibc 2.28 and kernel version 4.11 or newer.

The POSIX standard only defines three distinct timestamps to be stored for each file: the time of last data access, the time of last data modification, and the time the file status last changed.

Modern Linux filesystems, such as ext4, Btrfs, XFS (v5 and later) and JFS, do store the file creation time (aka birth time), but use different names for the field in question (crtime in ext4/XFS, otime in Btrfs and JFS). Linux provides the statx(2) system call interface for retrieving the file birth time for filesystems that support it since kernel version 4.11. (So even when creation time support has been added to a filesystem, some deployed kernels have not immediately supported it, even after adding nominal support for that filesystem version, e.g., XFS v5.)

As Craig Sanders and Mohsen Pahlevanzadeh pointed out, stat does support the %w and %W format specifiers for displaying the file birth time (in human readable format and in seconds since Epoch respectively) prior to coreutils version 8.31. However, coreutils stat uses the statx() system call where available to retrieve the birth time only since version 8.31. Prior to coreutils version 8.31 stat accessed the birth time via the get_stat_birthtime() provided by gnulib (in lib/stat-time.h), which gets the birth time from the st_birthtime and st_birthtimensec fields of the stat structure returned by the stat() system call. While for instance BSD systems (and in extension OS X) provide st_birthtime via stat, Linux does not. This is why stat -c '%w' file outputs - (indicating an unknown creation time) on Linux prior to coreutils 8.31 even for filesystems which do store the creation time internally.

As Stephane Chazelas points out, some filesystems, such as ntfs-3g, expose the file creation times via extended file attributes.

Answer 2

TLDR; Use stap ("SystemTap") to create your own kernel API. Demo of ext4 creation time extraction below.

You can extract the ext4 creation times on Fedora 19 systems. Here's mine:

$ uname -a
Linux steelers.net 3.11.1-200.fc19.i686.PAE #1 SMP Sat Sep 14 15:20:42 UTC 2013 i686 i686 i386 GNU/Linux

It's clear that the inodes on my ext4 partitions have the creation time. Here's a shell script that determines the inode associated with a filename and then augments the stat output with the creation time by using stap ("systemtap").

NB: This is just a demo and hugely inefficient since a kernel module is created, loaded, and unloaded for every execution. This is also probably very fragile as no error checking is performed. A proper kernel API would be preferable, but this script could be made much more efficient and read the creation times of multiple files/inodes.

[contents of stap_stat.sh]

#/bin/sh

my_inode_str=$(stat --printf="%i" $1)

stap - << end_of_stap_script
global my_offsetof
probe begin {
  system("stat $1");
  my_offsetof = &@cast(0,"struct ext4_inode_info")->vfs_inode;
}
probe kernel.function("ext4_getattr@fs/ext4/inode.c") {
  probe_inode=\$dentry->d_inode;
  if (@cast(probe_inode, "struct inode")->i_ino == $my_inode_str) {
    my_i_crtime = &@cast(probe_inode - my_offsetof,"struct ext4_inode_info")->i_crtime;
    printf("CrTime: %s GMT\n", ctime(@cast(my_i_crtime, "timespec")->tv_sec));
    printf("CrTime (nsecs): %d\n", @cast(my_i_crtime, "timespec")->tv_nsec);
    exit();
  }
}
end_of_stap_script

Here's a demo:

$ ll testfile
ls: cannot access testfile: No such file or directory
$ touch testfile
$ ./stap_stat.sh testfile
  File: ‘testfile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 4850501     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/    Rick)   Gid: ( 1001/    Rick)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2013-09-28 06:17:04.221441084 -0400
Modify: 2013-09-28 06:17:04.221441084 -0400
Change: 2013-09-28 06:17:04.221441084 -0400
 Birth: -
CrTime: Sat Sep 28 10:17:04 2013 GMT
CrTime (nsecs): 220441085
$ ll testfile
-rw-rw-r--. 1 Rick Rick 0 Sep 28 06:17 testfile
$ cat - >> testfile 
Now is the time ...
$ ll testfile 
-rw-rw-r--. 1 Rick Rick 20 Sep 28 06:18 testfile
$ ./stap_stat.sh testfile
  File: ‘testfile’
Device: fd02h/64770d    Inode: 4850501     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/    Rick)   Gid: ( 1001/    Rick)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2013-09-28 06:17:04.221441084 -0400
Modify: 2013-09-28 06:18:33.684374740 -0400
Change: 2013-09-28 06:18:33.684374740 -0400
 Birth: -
CrTime: Sat Sep 28 10:17:04 2013 GMT
CrTime (nsecs): 220441085
$ cat testfile 
Now is the time ...
$ ./stap_stat.sh testfile
  File: ‘testfile’
  Size: 20          Blocks: 8          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 4850501     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/    Rick)   Gid: ( 1001/    Rick)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2013-09-28 06:19:12.199349463 -0400
Modify: 2013-09-28 06:18:33.684374740 -0400
Change: 2013-09-28 06:18:33.684374740 -0400
 Birth: -
CrTime: Sat Sep 28 10:17:04 2013 GMT
CrTime (nsecs): 220441085
$ mv testfile testfile2
$ ./stap_stat.sh testfile2 
  File: ‘testfile2’
  Size: 20          Blocks: 8          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 4850501     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/    Rick)   Gid: ( 1001/    Rick)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2013-09-28 06:19:12.199349463 -0400
Modify: 2013-09-28 06:18:33.684374740 -0400
Change: 2013-09-28 06:20:45.870295668 -0400
 Birth: -
CrTime: Sat Sep 28 10:17:04 2013 GMT
CrTime (nsecs): 220441085
$ 

Answer 3

In theory, with GNU stat you could use stat -c '%w' or %W to get a file's creation date (aka birthtime).

In practice, most filesystems do not record that information and the linux kernel does not provide any way of accessing it.

The closest you can get is the file's ctime, which is not the creation time, it is the time that the file's metadata was last changed.

Linux Weekly News had an interesting article about this a few years back - File creation times.

Answer 4

In ext4 it is possible; because ext4 file-system stores the file creation time. But still, you will find that the stat command is unable to show the date, because I think the kernel is not having any APIs for this.

Anyway, the file birth time is stored in ext4 and you can find it out, although not by a direct method, but by using debugfs

sudo debugfs -R "stat /ABSOLUTE/PATH" /dev/sdxX | grep crtime

Answer 5

In OS X you can use ls -lU, stat -f%B, GetFileInfo -d, or mdls -n kMDItemFSCreationDate:

$ ls -lU
total 0
-rw-r--r--  1 lauri  staff  0 Apr 25 03:58 a
$ stat -f%B a
1398387538
$ stat -f%SB -t %Y%m%d%H%M a
201404250358
$ GetFileInfo -d a
04/25/2014 03:58:58
$ mdls -n kMDItemFSCreationDate a
kMDItemFSCreationDate = 2014-04-25 00:58:58 +0000

Answer 6

stat --printf='%w' yourfile   #human readable

stat --printf='%W' yourfile   #seconds from Epoch , 0 if unknown

Difference between FreeBSD and GNU\Linux on stat command:

If you call stat command in GNU\Linux it invokes the -x option, but in FreeBSD, you yourself should invoke the -x option.

See also What file systems on Linux store the creation time?

Notes: --printf is very useful in scripting....!

Answer 7

On OS/X or FreeBSD ls, it's the -U option. Linux now also stores the birth/creation time on most of its native file systems, but:

• the API to retrieve it - the statx() system call - is only available since kernel 4.11,
  • the GNU libc wrapper for statx() is available since glibc 2.28;
• and since coreutils 8.31, GNU stat can display it;
• and since 8.32, GNU ls can display it with --time=birth.

On ext4 filesystems, you can use debugfs to get it even in older systems:

$ sudo debugfs /dev/some/fs
stat /some/file
[...]
crtime: 0x53208d7a:9045625c -- Wed Mar 12 16:38:18 2014
[...]

(where /some/file is the path within that filesystem)

For NTFS filesystems, and assuming you're using ntfs-3g to mount it, see How do I get the creation date of a file on an NTFS logical volume?

If you have a recent enough Linux system, you can use xfs_io's statx subcommand to invoke the new statx() system call and get the birth time:

$ TZ=UTC0 xfs_io -c 'statx -v' /some/file
[...]
stat.btime = Thu Feb  7 17:11:20 2019
[...]

(here using UTC time with TZ=UTC0 as otherwise the date would be ambiguous as the UTC offset is not output). Or with statx -r which gives you the nanosecond part and a more easily parseable time:

$ xfs_io -c 'statx -r' /some/file
[...]
stat.btime.tv_sec = 1549559480
stat.btime.tv_nsec = 964691587
[...]

See also this other Q&A for a way to invoke statx() when your kernel is new enough to support it but when your libc is not.

With GNU stat 8.31 or newer on systems with glibc 2.28 or newer and a kernel 4.11 or newer:

$ stat /some/file | grep Birth:
 Birth: 2018-05-24 16:27:28.415875403 +0100
$ stat -c '%.9W %w' /some/file
1527175648.415875403 2018-05-24 16:27:28.415875403 +0100

With GNU ls 8.32 or newer on systems with glibc 2.28 or newer and a kernel 4.11 or newer:

$ ls -l --time=birth --full-time /some/file
-rw-r--r-- 1 stephane stephane 2333836 2018-05-24 16:27:28.415875403 +0100 /some/file

Traditionally, Unix didn't store a creation time.

Note that that value maybe has less meaning than you might think.

The modification time reflects the age of the data in that file, the access time when it was last accessed, the inode change-time is very useful to backup software for instance, because you know nothing about that file has changed since that time (except possibly its full path for which you can have a look at the ctime of its directory components).

The creation time is when the inode spawn into existence (well had a link count going from 0 to 1, that inode might have been allocated and removed in a previous life), it doesn't reflect the age of any data associated with that file (data is written after the file has been created), it doesn't tell us whether a file by that path went into existence at that time (the file we're looking at can have been created with a different path and linked or moved there later).

Answer 8

Check this out:

# the last arg is the device to scan in.
debugfs -R 'stat /home/renich/somefile' /dev/sda1

BTW, this works on ext4 only. I haven't found a solution for BtrFS... yet ;)

Answer 9

I am using ubuntu, and most files are under ext4 file system, so we can ignore cases in other ones, like Btrfs, XFS (v5 and later) and JFS.

The standard ext4 Linux file system allocates space for a file-creation timestamp in its internal file system structures, but this hasn’t been implemented yet (I tried on Ubuntu 20.04)

Use this as an alternative:

stat --format='%z' {{YOUR_file}} 

%z: time of last status change, human-readable. (aka ctime)
ctime: Changed timestamps, aren’t referring to changes made to the contents of a file. Rather, it’s the time at which the metadata related to the file was changed. File permission changes, for example, will update the changed timestamp.

atime v.s ctime v.s. mtime:
https://www.howtogeek.com/517098/linux-file-timestamps-explained-atime-mtime-and-ctime/

more about metadate of a file:
https://www.cs.columbia.edu/~smb/classes/s06-4118/l21.pdf