6

How can i see when a file was created. I have looked at man page

ls -lc is for last modification of file status

ls -lu for access time

ls -l not exactly indicated which time, last changed?

I tried these, but they don't give me time the file was created.

Marda
  • 61

1 Answers1

8

On OS/X or FreeBSD, it's the -U option. Linux now also stores the birth/creation time on most of its native file systems, but there's no API to retrieve it yet (2018 edit: since kernel 4.11, there is now a statx() system call, and since glibc 2.28 a libc wrapper for it and since coreutils 8.31, GNU stat can display it, and (2021 edit) since 8.32 GNU ls can display it with --time=birth).

On ext4 filesystems, you can use debugfs to get it though:

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

Stéphane Chazelas
  • 544,893
  • 1
    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 Mar 14 '14 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 Mar 14 '14 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 Mar 14 '14 at 15:59