== Unix files do not have creation times

There is a persistent belief, held by a large assortment of even fairly
experienced people, that Unix files have a creation time. They don't.

The belief generally arises because one of the three times that all
Unix files have is called _ctime_, going along with _mtime_ and _atime_.
However, the 'c' stands for 'change', not 'creation'; an inode's _ctime_
is updated more or less any time various data fields in the inode itself
are changed.

(The exact details of which system calls should update _ctime_ are best
dug out of specifications. Then you get to test it to be sure, because
some systems and some filesystems get it wrong, most commonly by not
updating the _ctime_ of a _rename()_ed file.)

So while a file creation time might be nice to have, Unix doesn't
have it, and _ctime_ is not what you might think it is.

=== The problems with an inode creation time

I suspect that two of the reasons that Unix doesn't have an inode
creation time is that it's hard to come up with just what should count
as file 'creation' in order to be useful, and that inode creation time
would be less useful than people think because it's too low level.

The most straightforward answer for inode creation time would be
'whenever an inode is allocated'. This has the virtue of being
completely technically correct, and the flaw of being near useless in
practice, since things like '_> file_' in the shell on an existing file
merely truncate the file and don't delete it and create a new one. If
you add 'truncate a file to 0 length' in there, the question becomes
what else is destructive enough to count.

The need to account for truncation points to the reason inode creation
time is too low-level: what people are really interested is the
creation time of *logical* files, not of inodes. A careful program
writing to a logical file may use [[several inodes under the covers
SafelyUpdatingUnixFiles]]; at this point the 'creation time' of your
document, as reported by Unix, turns into 'the most recent time you
asked your editor to save it'.

=== Sidebar: Why _rename()_ updates _ctime_, and should

There are two reasons why _rename()_ updates _ctime_: the theoretical
and the practical.

The theoretical one is that, logically speaking, rename is a link
followed by an unlink; if you implemented it literally as that, you
would update the _ctime_ (twice, not that you'd notice).

The practical one is that updating _ctime_ on rename makes life easier
for backup programs during incremental backups; it makes _ctime_ a
reliable indication of 'something important has changed with this file,
better back it up'.

(The pragmatic reason is that real backup programs expect this behavior,
because _rename()_ has done this ever since BSD introduced it.)