12 Mar
2025
12 Mar
'25
3:46 p.m.
On Wed, Mar 12, 2025 at 1:57 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
As part of a discusion on the Linux kernel mailing
list, there was an
assertion that ctime was orginally "creation time".
From the v7 sources in TUHS, we can see:
struct dinode
{
unsigned short di_mode; /* mode and type of file */
short di_nlink; /* number of links to file */
short di_uid; /* owner's user id */
short di_gid; /* owner's group id */
off_t di_size; /* number of bytes in file */
char di_addr[40]; /* disk block addresses */
time_t di_atime; /* time last accessed */
time_t di_mtime; /* time last modified */
time_t di_ctime; /* time created */
};
... although the v7 kernel sources does seem to update ctime when the
inode metadata changes, regardless of what the coment in
/usr/src/sys/h/ino.h might say.
More interestingly, this comment seems to continue in newer versions
up to 3BSD, and then the comments becomes "change time" in BSD 4.2,
probably coincident with the File System Implementation?
The best we can guess is that the change from "creation time" to
"inode change time" happened sometime between 1979 and 1982. Does
anyone who was around can give the story about how and when this
happened?
I chased this through the various history archives once, and my
conclusion was that the original comment was always misleading. As
you say, in 7th Edition it's updated in `iupdat` whenever `ICHG` is
set in the inode's `i_flag`; so basically whenever the inode itself
changes, or when the file is written (ICHG is set in `writei`). If the
intent was to capture the creation time, I don't know why `i_ctime`
wouldn't be set in `maknode` and its value otherwise unchanged in
`iupdat`. My guess is that the comment was the result of initial
exploration of an idea that evolved very quickly, and never reflected
reality (at least not for very long).
Further, I believe BSD simply changed the documentation to reflect
reality. It makes sense that they would do this around the time the
FFS was implemented (I see it updated in 4.1c.1, at least), when
presumably they would have needed to be deep into understanding the
existing filesystem's semantics in order to faithfully reproduce them
in the new implementation. I imagine someone sitting at a terminal
connected to some VAX asking much the same questions we are now.
Funny how history repeats itself.
- Dan C.