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
However, the 'c' stands for 'change', not 'creation'; an inode's
is updated more or less any time various data fields in the inode itself
(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
ctime of a
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; 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'.
ctime, and should
There are two reasons why
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
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,
rename() has done this ever since BSD introduced it.)