In UNIX, each file has three timestamps associated with it:
- atime
- mtime
- ctime
The sad thing is that while almost every system administrator understands atime (the last time the file was accessed) and mtime (the last time the file was modified), that many are confused about the purpose of ctime. In fact, this weekend I got into a long discussion with another very skilled system administrator who did not agree to my definition of ctime. Since then, I have queried other system administrators.
It seems that the UNIX community as a whole believes that ctime stands for “creation time”, and only gets set when a file is initially created, or manually tampered with using ‘touch’. I’m not sure where this disinformation came from, but I believed it for a while myself. Here’s a more accurate description of ctime:
ctime: ctime stands for “change time”, which refers to the last time the contents of the inode for a file has changed, rather than mtime, which refers to the last time the data for a file has changed.
That’s right. If you chmod a file, the ctime for that file will change, or at least on Linux, Mac OS X, and Solaris (and anything else claiming to be POSIX). If you create a new hard link to a file, the ctime will change. Often it will change by editing the file or just redirecting output to it. Let me give a demonstration on a Linux 2.4.29 box:
% stat new.file | egrep 'Modify|Change' Modify: 2006-01-11 20:28:18.000000000 -0500 Change: 2006-01-11 20:28:18.000000000 -0500 % chmod 600 new.file % stat new.file | egrep 'Modify|Change' Modify: 2006-01-11 20:28:18.000000000 -0500 Change: 2006-01-11 20:28:31.000000000 -0500
The question is, where did this fallacy that ctime is the “creation time” start? It’s an easy enough assumption to make. You figure the operating system gives you a file modification time as “mtime”, why wouldn’t it give you a file creation timestamp as “ctime”? Why on earth would we want to have two different modification timestamps?
I think the source of the confusion is that realistically, most files don’t have their permissions changed after they are created. Sure, in a multi-user server environment, you’ll see it more commonly, but how often do you go around resetting file permissions on your desktop?
One question that I haven’t had explained to me is why renaming a file changes it’s ctime. The filename is not held within the inode contents, but is held within the directory entry.
Honestly, I think UNIX deserves a file creation timestamp, like Windows has with NTFS. There are some dissenting opinions however, primarily concerning the philosophical question when is a file really created?. I think this squabble over philosophy is a bunch of hogwash however. I say that creation time should be defined as the first time the inode existed. I look at the filesystem as a great big file cabinet, and people have been sorting their files by creation date for a long time now, why shouldn’t I be able to do so?
Here’s a hall of shame for people spreading misinformation about ctime by referring to it as “creation time”:
- KDE 3.3 Documentation: KTar Class
- Debian (Popularity Contest)
- TCL: Filesystem Reflection API
- ReiserFS Documentation
- STAR (arguable, I guess)
- A.P. Lawrence
- Tufts University
- derkeiler
BTW, a little bit of trivia: When a file is deleted, many operating systems set the ctime to the time of the file’s deletion. Why is this important? Forensics.
Update and Correction, 2005-01-12:
Not wanting to be proven wrong, my old friend, David Wimsey, let me know that this article is not necessarily accurate. I had neglected to mention that some filesystems may store the birth time of an inode (creation time). I couldn’t think of any filesystems that did, so I glossed over the issue. David swore that FreeBSD stored the creation timestamp for each file, so I dug into Design and Implementation of the FreeBSD Operating System. To my surprise, the inode diagram indicated 4 timestamps. It then goes on to say:
The time that the file was created, when it was most recently read and written, and when its inode was most recently updated by the system
I’ll be damned. It took some google searching to locate the name of this 4th field. I found some notes on Kirk McKusick’s NYCBSDCon Keynote which talks about changes to UFS/FFS. It mentions the fourth timestamp, called birth time (btime). I also found an interesting perl.beginners thread that mentions btime. It also mentions that perl doesn’t have a way of retrieving the birth time of a file just yet. Surprisingly, neither does the FreeBSD find command. The only userland utility I have found that understands this birth time is stat(1). Hopefully other filesystems will add btime in their newer revisions. Why wouldn’t they?
What can I say, I learn something new every day.
Add New Comment
Viewing 8 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Add New Comment
Trackbacks
(Trackback URL)
June 27, 2006 at 08:09
File Creation Dates on Mac OS X: Clash of the Cultures... Yesterday, an [interesting discussion](http://lists.apple.com/archives/Darwin-dev/2006/Jun/thrd3.html#00271) about file metadata has begun on ...