Join Unix & Linux

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?

Linux doesn't keep track of the creation time since it is not required by POSIX. However, Mac OS X does with the HFS filesystem — look under "birth time" in stat(1). — 200_success, Commented Sep 18, 2013 at 5:15
Fedora 19 ext4 filesystems do set file creation times. I'm sure there are many more examples. See answer below that uses stap to retrieve creation times. — rickhg12hs, Commented Oct 15, 2013 at 13:11
stackoverflow.com/questions/14842195/… explains your problem — David Wilkins, Commented Mar 14, 2014 at 13:59

rickhg12hs · Accepted Answer · 2013-09-28 14:44:16Z

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
$

Ok, that is just cool. +1 for using stap, monkey patching the linux kernel, awesome. — Chris Magnuson, Commented Jun 24, 2015 at 1:20
@ChrisMagnuson: debugfs + stat allow to get crtime without monkey patching the kernel. — jfs, Commented Jul 26, 2016 at 13:41

Paulo Tomé · Accepted Answer · 2020-02-26 09:04:44Z

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.

Update: Since Linux 4.11, it is actually possible to retrieve crtime (on filesystems that support it). — Carl Winbäck, Commented Jan 20, 2022 at 8:15

Community · Accepted Answer · 2018-12-11 18:29:21Z

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

If /dev/sdxX is mounted in /some/path and the file is /some/path/some/file, the path to be specified is only some/file: its path must be referred not to the filesystem root, but to the mountpoint. Otherwise, the file won't be found. — BowPark, Commented Jun 27, 2018 at 13:33

Lri · Accepted Answer · 2014-04-25 01:07:50Z

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

Very useful, thanks! Evidently there's more than one way to do it. — GDP2, Commented Feb 17, 2020 at 17:52

Community · Accepted Answer · 2017-04-13 12:37:00Z

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

// , Tried this on a CEntOS 6 machine, and all I got were question marks: $ stat --printf='%w' ~/dump.rdb ? Maybe my file system doesn't support stat with %w. — Nathan Basanese, Commented Aug 21, 2015 at 19:23

Stéphane Chazelas · Accepted Answer · 2024-07-30 16:15:15Z

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

Note with debugfs the paths used here must be either relative or absolute (leading / is not needed) to the root of the filesystem and not the system root. — Graeme, Commented Mar 14, 2014 at 14:05
@Graeme, debugfs has a cd command, so relative paths are relative to that debugfs working directory managed by that cd command, but yes the absolute paths are paths in that file system, so relative to the root of the filesystem, I've updated the answer. — Stéphane Chazelas, Commented Mar 14, 2014 at 14:21
From your last part, an example of where the creation time is effectively invalidated is when programs update files by writing the data to a different file and atomically moving the location of the new file to the original. The inode and creation time for the new file is used rather than the original, as might be expected. Two programs that do this by default are rsync and vim. — Graeme, Commented Mar 14, 2014 at 15:59

Renich · Accepted Answer · 2015-12-28 23:40:21Z

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

That's pretty much what beginer's answer says... isn't it ? — don_crissti, Commented Dec 28, 2015 at 23:49

Good Pen · Accepted Answer · 2021-11-13 05:12:27Z

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

It has been implemented. Use 20.10 or newer and stat should work OOTB for showing creation time on ext4. — muru, Commented Nov 13, 2021 at 3:35

`stat -c '%w' file` on filesystems that store creation time.	`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](https://unix.stackexchange.com/a/119699/43779).	Note that on Linux this requires [`coreutils` 8.31, `glibc` 2.28 and kernel version 4.11 or newer](https://unix.stackexchange.com/a/119699/43779).
18 identical lines skipped

Stack Exchange Network

Suggested edits

Strictly Necessary Cookies

Performance Cookies

Functional Cookies

Targeting Cookies