Wandering Thoughts archives

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