1. 32

  2. 6

    Note that file creation time can be very misleading. It exists in Windows, and in hindsight, it seems like a mistake.

    If you imagine a simple world where you create a file, and your editor opens that file, and when you save, it modifies the contents of that file, then file creation time means the first time you created the file.

    But what if you editor deletes the file first, then writes new contents? What if your editor renames the old file, writes the new contents to a new file, then deletes the old file? In these cases, unless the editor is manually propagating creation times, that type of metadata gets lost. These types of patterns are surprisingly common, because they can ensure that you have either your old data or your new data; they don’t destroy your old data without first knowing that the new data can be successfully written. (In fairness, without manual action this will lose all kinds of metadata, but when introducing new metadata the chance of it being lost is very high.)

    So as far as I can tell, file creation time has little value aside from forensics. As a user, you just can’t assume it means anything, at least outside of a particular application on a particular file system.

    1. 5

      Intuitively, one might expect ctime to record the creation time of a file. However, ctime records the last time when the metadata of a file was changed.

      Today I learned something.

      1. 3

        Nice writeup, ran into this exact issue a few months ago. Now I just need to wait for my favorite programming language X to reexport the same fields so I can make actual use of them…

        1. 1

          Now I just need to wait for my favorite programming language X to reexport the same fields so I can make actual use of them

          Tell me about it! I few months back I got bitten by the fact that Python’s socket.settimeout() does something completely unrelated to SO_RCVTIMEO/SO_SNDTIMEO.

        2. 2

          I learned about this months ago and I have a one liner I use as a workaround, since, funnily enough, the stat tool actually does know about birth date, but it’s a little obfuscated.

          fd -tf -d1 -0 | \
            xargs -0 stat -c '%W %n' | \
            sort -k1,1n | \
            cut -d' ' -f2- | \
            fzf --no-sort --print0 | \
            xargs -0r open

          I use fzf as a file opener UI here with the pre-sorted files by birth time. The relevant bit is stat -c '%W %n' which formats the output (this should be o.k. even for files with spaces in the name), and %W represents birth time.

          When I learned this, I was confounded because I checked the man pages man 3 stat and the birth time wasn’t there, so I looked into stat’s source code, and it turns out that they just have a custom implementation which looks it up.

          It’s perplexing to me, because it’s honestly the most useful sorting metric after modified time.

          1. 1

            It probably depends on the file system if it is available? For my ext4 home directory stat outputs something like this:

            Access: 2019-06-22 20:05:51.326934512 +0200
            Modify: 2019-03-09 20:50:54.475030909 +0100
            Change: 2019-03-09 20:50:54.487028674 +0100
            Birth: -

            No birth date available.

            1. 2

              Yeah, birth date is highly file system dependent. Although it’s weird that ext4 wouldn’t have it, since mine does (also ext4).

          2. 1

            Am I the only one irritated by

            Access: (0775/drwxrwxr-x)  Uid: ( 1000/ anmol)   Gid: ( 1000/ anmol)
            Access: 2019-06-23 10:49:04.056933574 +0000

            or is it just me? :-)

            Maybe the first “Access” could be replaced with “Rights”? (“Permissions” would be better, but that wouldn’t line up with the following entries.)

            1. 5

              It’s just you, everyone else uses -c rather than screen scraping :-)