On Sat, Jun 12, 2021 at 02:43:22AM -0400, Polyna-Maude Racicot-Summerside wrote: > If you look at the specifications for all the different "ext2/3/4" > filesystem specifications, there's no place it says "store all the > passed date possible". What you see in ls -l is what's in the inode. > There's no secret hidden place with the dates of the file.
This is incorrect. On Sat, Jun 12, 2021 at 06:46:44AM -0400, Dan Ritter wrote: > No. There are three timestamps, and none of them are original > creation times. > > atime is last access time, and most modern systems have either > stopped recording this, or set it only when mtime is written. > > mtime is last modification time, or if you prefer, the last time > it was written to. > > ctime is not creation time; it is the last time the inode was > changed. ctime is updated when the permissions or ownership of > the file changes, or the number of links changes, or the number > of blocks changes... Those are the POSIX file system semantics. If you only look at the *sane* parts of the Linux APIs, then that's all you'll be able to work with. It's certainly all that's guaranteed across the various Unix-type file systems. However, ext4 actually *does* store a creation time. It's hidden in a field that isn't exposed via the normal stat(2) interface. Virtually none of the standard userland tools are able to see it. On bullseye, stat(1) has been altered to make "birth" (a.k.a. creation) time visible. Here's a demonstration. My home directory is on an ext4 file system with these mount options: /dev/sda8 on /home type ext4 (rw,relatime) unicorn:~$ rm x unicorn:~$ echo x > x unicorn:~$ sleep 5; chmod 600 x unicorn:~$ stat x File: x Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 808h/2056d Inode: 803372 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/ greg) Gid: ( 1000/ greg) Access: 2021-06-12 08:53:06.179415149 -0400 Modify: 2021-06-12 08:53:06.179415149 -0400 Change: 2021-06-12 08:53:20.391429504 -0400 Birth: 2021-06-12 08:53:06.179415149 -0400 The "Change" line (ctime) is updated when the chmod runs, but the "Birth" line is not. unicorn:~$ echo y >> x unicorn:~$ stat x File: x Size: 4 Blocks: 8 IO Block: 4096 regular file Device: 808h/2056d Inode: 803372 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/ greg) Gid: ( 1000/ greg) Access: 2021-06-12 08:53:06.179415149 -0400 Modify: 2021-06-12 08:53:40.787450117 -0400 Change: 2021-06-12 08:53:40.787450117 -0400 Birth: 2021-06-12 08:53:06.179415149 -0400 Writing to the file updates the mtime and ctime fields, but not Birth. Now, the bad news: if you're on buster or older, this won't work. The tools to work with ext4's Birth field simply didn't exist, or didn't work. And if you're on ext3 or many other file systems, these fields simply don't exist in the file system, so it won't matter what tools you use. If you search the web, you can find other approaches to extracting the Birth field on ext4 without working userland tools. Many of them involve running debugfs with sudo. I wouldn't recommend doing this, other than once as a proof of concept just to see that it does in fact "work". The top answer on <https://unix.stackexchange.com/questions/91197/how-to-find-creation-date-of-file> gives some detailed explanations of how ugly this whole thing truly is.
