[TUHS] When/how did ctime change from inode "creation" to "change" time?

[TUHS] When/how did ctime change from inode "creation" to "change" time?

[Theodore Ts'o]

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?

					- Ted

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

Or perhaps the comment was wrong?

I do remember being confused by it.

-rob


On Wed, Mar 12, 2025 at 1:19 PM Theodore Ts'o <tytso@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?
>
>                                         - Ted
>

[-- Attachment #2: Type: text/html, Size: 2511 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Dave Horsfall]

On Tue, 11 Mar 2025, Theodore Ts'o wrote:

> As part of a discusion on the Linux kernel mailing list, there was an 
> assertion that ctime was orginally "creation time".

[...]

It's been "inode change time" for as long as I can remember (and that's 
since the 70s); I have no idea what the Penguins are on about, but I've 
never given them much credence anyway.

-- Dave

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Theodore Ts'o]

On Wed, Mar 12, 2025 at 01:33:14PM +1100, Dave Horsfall wrote:
> On Tue, 11 Mar 2025, Theodore Ts'o wrote:
> 
> > As part of a discusion on the Linux kernel mailing list, there was an 
> > assertion that ctime was orginally "creation time".
> 
> [...]
> 
> It's been "inode change time" for as long as I can remember (and that's 
> since the 70s); I have no idea what the Penguins are on about, but I've 
> never given them much credence anyway.

OK, how much credence would you give to Ritchie and Thompson writing
in The Bell System Technical Journal, Vol. 57, No. 6, July-August
1978, page 1914[1], where they state that the i-node contains:

   (v) time of creation, last use, and last modification
       ^^^^^^^^^^^^^^^^

[1] https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/bstj57-6-1905.pdf

There are some of us Penguins who actually cared enough to do some
research using the TUHS archives...    :-)

						- Ted

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Larry McVoy]

I had the exact same reaction, I think I saw the time created and liked 
that semantic.  When it morphed into inode change time, as a source
management guy, I'd much rather have create time than changed time
since I already got access and modified times.

On Wed, Mar 12, 2025 at 01:31:37PM +1100, Rob Pike wrote:
> Or perhaps the comment was wrong?
> 
> I do remember being confused by it.
> 
> -rob
> 
> 
> On Wed, Mar 12, 2025 at 1:19???PM Theodore Ts'o <tytso@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?
> >
> >                                         - Ted
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Rik Farrow]

[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]

As someone interested in security, I liked the concept of 'inode change
time'. Creation time is certainly a change, so that fits too.

Changing permissions or overwriting of binaries with trojans was a popular
hacking technique in the 90s. Trojan installation scripts would often
contain commands (touch) to replace the inode modify times, but that
changed the inode change times too, making ctime a more reliable indicator
of tampering.

The workaround for that was to change the system clock to the desired
ctime, modify the binary, then change the system clock back. Fortunately,
setting system clocks back arbitrarily no longer works in systems I've
used. Perhaps someone knows more about this change?

Rik

On Tue, Mar 11, 2025 at 7:49 PM Larry McVoy <lm@mcvoy.com> wrote:

> I had the exact same reaction, I think I saw the time created and liked
> that semantic.  When it morphed into inode change time, as a source
> management guy, I'd much rather have create time than changed time
> since I already got access and modified times.
>
> On Wed, Mar 12, 2025 at 01:31:37PM +1100, Rob Pike wrote:
> > Or perhaps the comment was wrong?
> >
> > I do remember being confused by it.
> >
> > -rob
> >
> >
> > On Wed, Mar 12, 2025 at 1:19???PM Theodore Ts'o <tytso@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?
> > >
> > >                                         - Ted
> > >
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

[-- Attachment #2: Type: text/html, Size: 3978 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

So I think  I have to disagree about what it means in v7, comments
notwithstanding.

iupdat() has:
                if(ip->i_flag&ICHG)
                        dp->di_ctime = time;

ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few others,
this was a quick peek).

So even in v7, ctime means any changes to metadata / inode data. At least
for some definition of "any".

Btw, it looks like this was named IUPD in v6 and did similar things. In v6
it is updated in iput when IUPD is set. But it looks like ctime and mtime
are folded together. So v7 is the first edition that has ctime and the code
implements any change to metadata from my reading.

Warner

On Tue, Mar 11, 2025 at 8:19 PM Theodore Ts'o <tytso@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?
>
>                                         - Ted
>

[-- Attachment #2: Type: text/html, Size: 2857 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Alec Muffett]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Wed, 12 Mar 2025, 05:57 Theodore Ts'o, <tytso@mit.edu> wrote:

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

I've worked at one company where policy was that comments were considered a
risk for precisely this reason, and where if code were not written clearly
enough to be understood without comments, it was generally considered a bug.

Perhaps the comment is just a brain fart?

-a

[-- Attachment #2: Type: text/html, Size: 1470 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Theodore Ts'o]

On Tue, Mar 11, 2025 at 09:38:39PM -0600, Warner Losh wrote:
> So I think  I have to disagree about what it means in v7, comments
> notwithstanding.
> 
> iupdat() has:
>                 if(ip->i_flag&ICHG)
>                         dp->di_ctime = time;
> 
> ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few others,
> this was a quick peek).
> 
> So even in v7, ctime means any changes to metadata / inode data. At least
> for some definition of "any".
> 
> Btw, it looks like this was named IUPD in v6 and did similar things. In v6
> it is updated in iput when IUPD is set. But it looks like ctime and mtime
> are folded together. So v7 is the first edition that has ctime and the code
> implements any change to metadata from my reading.

Yeah, Al Viro (the chief Pengiun VFS maintainer) had made a similar
observation to yours.  After I pointed out the Ritchie and Thompson
Unix paper, Al also pointed out that comment could be found in the
filsys.5 man page[1] dating from January 1979, also says "creation
time" although that is an excerpt from the ino.h header file, the
comment of which, as I said, persisted into 2BSD and 3BSD.

[1] https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/man/man5/filsys.5

So this is why we were wondering whether if there was sometime when it
actually *was* creation time, perhaps in between the v6 and v7
releases, or whether it was always just a comment brain fart, which
also managed to make it into a published paper and the filsys.5 man
page, with no one caring enough to fix it until several years went by,
and perhaps only at Berkeley.  (I'm curious when if ever it got fixed
in the AT&T sources, but I haven't gone and checked those sources
yet.)

It's because we were genuinely interested that I decided to ask on
TUHS list.  Some of us *do* care about the Unix history.  :-)

     	    	       	    	 - Ted

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Well, it's creation time right after the file is created. I mean that's
kind of a joke, but also possibly an explanation for the comment, if you
consider the mindset of the person writing the code at the time. Then they
worked on the code some more and things moved along.

In short, it could well be an honest, original mistake.

-rob


On Wed, Mar 12, 2025 at 10:43 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Tue, Mar 11, 2025 at 09:38:39PM -0600, Warner Losh wrote:
> > So I think  I have to disagree about what it means in v7, comments
> > notwithstanding.
> >
> > iupdat() has:
> >                 if(ip->i_flag&ICHG)
> >                         dp->di_ctime = time;
> >
> > ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few
> others,
> > this was a quick peek).
> >
> > So even in v7, ctime means any changes to metadata / inode data. At least
> > for some definition of "any".
> >
> > Btw, it looks like this was named IUPD in v6 and did similar things. In
> v6
> > it is updated in iput when IUPD is set. But it looks like ctime and mtime
> > are folded together. So v7 is the first edition that has ctime and the
> code
> > implements any change to metadata from my reading.
>
> Yeah, Al Viro (the chief Pengiun VFS maintainer) had made a similar
> observation to yours.  After I pointed out the Ritchie and Thompson
> Unix paper, Al also pointed out that comment could be found in the
> filsys.5 man page[1] dating from January 1979, also says "creation
> time" although that is an excerpt from the ino.h header file, the
> comment of which, as I said, persisted into 2BSD and 3BSD.
>
> [1]
> https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/man/man5/filsys.5
>
> So this is why we were wondering whether if there was sometime when it
> actually *was* creation time, perhaps in between the v6 and v7
> releases, or whether it was always just a comment brain fart, which
> also managed to make it into a published paper and the filsys.5 man
> page, with no one caring enough to fix it until several years went by,
> and perhaps only at Berkeley.  (I'm curious when if ever it got fixed
> in the AT&T sources, but I haven't gone and checked those sources
> yet.)
>
> It's because we were genuinely interested that I decided to ask on
> TUHS list.  Some of us *do* care about the Unix history.  :-)
>
>                                  - Ted
>

[-- Attachment #2: Type: text/html, Size: 3494 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Theodore Ts'o]

On Tue, Mar 11, 2025 at 08:02:19PM -0700, Rik Farrow wrote:
> As someone interested in security, I liked the concept of 'inode change
> time'. Creation time is certainly a change, so that fits too.
> 
> Changing permissions or overwriting of binaries with trojans was a popular
> hacking technique in the 90s. Trojan installation scripts would often
> contain commands (touch) to replace the inode modify times, but that
> changed the inode change times too, making ctime a more reliable indicator
> of tampering.

I have fond memories of looking at the Larn (or was it Hack/Nethack?)
sources and seeing that it checked ctime to prevent people from
cheating by saving and restoring the game save file, since ctime
couldn't be set without either changing the system clock or directly
accessing the file system (or kernel memory) and messing with the
on-disk inode directly.

> The workaround for that was to change the system clock to the desired
> ctime, modify the binary, then change the system clock back. Fortunately,
> setting system clocks back arbitrarily no longer works in systems I've
> used. Perhaps someone knows more about this change?

Multics doesn't allow you to set the the clock back, since they use
accurate time as part of their file system correctness semantics.  It
messes with Multics' unique_id abstraction, with their file system
depends on heavily.

Setting system clocks arbitrarily *does* work on most Unix/Linux
systems I've used, although it can cause strange results[1], and you
might have to disable the time daemon first.  NSA's SELinux can also
prevent you from setting the system clock, so you might have to
disable it if it is active and you want to play with system time.

[1] There are some hueristics that fsck.ext4 uses which can get fooled
if time goes backwards, but they are much more minor compared with
what could happen with Multics.

> On Tue, Mar 11, 2025 at 7:49 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > I had the exact same reaction, I think I saw the time created and liked
> > that semantic.  When it morphed into inode change time, as a source
> > management guy, I'd much rather have create time than changed time
> > since I already got access and modified times.

Yeah, that was actually the cause of the thread on the Linux Kernel
mailing list.  There are some people who want Linux to have a
"creation time" which works like the Windows time stamp, which can be
arbitrarily set by an unprivileged process.  The arguments are the
ones you've made; in addition, some people want to be able to have a
date which survives being copied from one backup file system to
another, so they can know when a photo or video was created without
having to access the in-line metadata.

What Linux currently has a "birth time" field which can't be changed
by a utimes(2)-like system call.  The rationale for that is this is
what XFS had implemented back in the SGI days, and xfs had support for
"birth time" with SGI semantics.  The argument for that approach is
that it can be a security thing, which is useful for people doing
forensics analysis.  I also wonder if this was used in the
construction of NFS file handles (which for other OS's might be done
via the i_version or i_generation fields, although the arguments about
when *those* fields should be incremented are interesting and there
isn't much agreement about that).

>From there was someone who argued that Unix had originally had ctime
as "creation time", and that ctime was "useless" (by which, that
person was arguing that it was useless for *him*).  I then pointed out
that while there may have been comments going back to V7 days saying
"creation time", even the comment was changed to "change time" by 1972
in the BSD 4.3 sources, and we weren't going to change ctime semantics
that had been settled for over four decades just because someone
wanted Windows compatibility.

If the answer is "We have always been at war with Oceania" that would
be interesting; which is why I wanted to ask what the history behind
the file comment might have been.  Was the comment and the Ritchie and
Thompson paper *ever* correct on this point?

Cheers,

						- Ted

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

On Wed, 12 Mar 2025 at 07:43, Theodore Ts'o <tytso@mit.edu> wrote:

> On Tue, Mar 11, 2025 at 09:38:39PM -0600, Warner Losh wrote:
> > So I think  I have to disagree about what it means in v7, comments
> > notwithstanding.
> >
> > iupdat() has:
> >                 if(ip->i_flag&ICHG)
> >                         dp->di_ctime = time;
> >
> > ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few
> others,
> > this was a quick peek).
> >
> > So even in v7, ctime means any changes to metadata / inode data. At least
> > for some definition of "any".
> >
> > Btw, it looks like this was named IUPD in v6 and did similar things. In
> v6
> > it is updated in iput when IUPD is set. But it looks like ctime and mtime
> > are folded together. So v7 is the first edition that has ctime and the
> code
> > implements any change to metadata from my reading.
>
> Yeah, Al Viro (the chief Pengiun VFS maintainer) had made a similar
> observation to yours.  After I pointed out the Ritchie and Thompson
> Unix paper, Al also pointed out that comment could be found in the
> filsys.5 man page[1] dating from January 1979, also says "creation
> time" although that is an excerpt from the ino.h header file, the
> comment of which, as I said, persisted into 2BSD and 3BSD.
>
> [1]
> https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/man/man5/filsys.5
>
> So this is why we were wondering whether if there was sometime when it
> actually *was* creation time, perhaps in between the v6 and v7
> releases, or whether it was always just a comment brain fart, which
> also managed to make it into a published paper and the filsys.5 man
> page, with no one caring enough to fix it until several years went by,
> and perhaps only at Berkeley.  (I'm curious when if ever it got fixed
> in the AT&T sources, but I haven't gone and checked those sources
> yet.)


The comment in the source had not been changed as of SVR4; however between
SVR1 and SVR2 the manpage changed.  For example, from looking at the
sources on the CSRG DVD:

S5_1/usr/man/u_man/man4/inode.4:        time_t  di_ctime;       /\(** time
created \(**/
S5_2.0/usr/man/p_man/man4/inode.4:      time_t  di_ctime;       /\(** time
of last file status change \(**/

and then again in SVR4:
S5_4.0/doc/MANPAGES/4/gen/inode_s5:     time_t  di_ctime;       /\(** time
status last changed \(**/

All of the later Research versions (v[8-10]) have
time_t  di_ctime;       /* time created */
in that struct.

-Henry

[-- Attachment #2: Type: text/html, Size: 3277 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[arnold]

Rob Pike <robpike@gmail.com> wrote:

> Well, it's creation time right after the file is created. I mean that's
> kind of a joke, but also possibly an explanation for the comment, if you
> consider the mindset of the person writing the code at the time. Then they
> worked on the code some more and things moved along.
>
> In short, it could well be an honest, original mistake.

This is what it feels like to me.

FWIW, the "creation time" comment made it's way into the Unix programming
appendix in K&R-1. It was there in the early printings of K&R-2 until
I pointed it out to Brian... :-)

I don't doubt that it being in K&R was also a source of misunderstanding
for many people.

Arnold

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Dan Cross]

On Wed, Mar 12, 2025 at 1:57 AM Theodore Ts'o <tytso@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.

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Bakul Shah via TUHS]

On Mar 12, 2025, at 8:46 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> 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).

The comment "time created" is not wrong from a deep philosophical
point of view: Every time the file changes it is born again ;-)

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Wed, Mar 12, 2025 at 8:07 AM Theodore Ts'o <tytso@mit.edu> wrote:

> I have fond memories of looking at the Larn (or was it Hack/Nethack?)
> sources and seeing that it checked ctime to prevent people from
> cheating by saving and restoring the game save file, since ctime
> couldn't be set without either changing the system clock or directly
> accessing the file system (or kernel memory) and messing with the
> on-disk inode directly.


Rogue did it first. :) They also store the inode number.

[-- Attachment #2: Type: text/html, Size: 866 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

According to my 1985 book *Advanced UNIX Programming*, the st_ctime member
is "the status-change time, updated when the file is written or when the
mode, owner, group, link count, or modification time is changed. Updated
when the access time is changed explicitly via utime, but not when the file
is read." I don't ever remember st_ctime being the creation time.

I probably got that information from whatever UNIX manuals I was reading at
the time.

Marc

On Tue, Mar 11, 2025 at 8:57 PM Theodore Ts'o <tytso@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?
>
>                                         - Ted
>


-- 
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.

[-- Attachment #2: Type: text/html, Size: 2809 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Dave Horsfall]

On Wed, 12 Mar 2025, Theodore Ts'o wrote:

> I have fond memories of looking at the Larn (or was it Hack/Nethack?)
> sources and seeing that it checked ctime to prevent people from
> cheating by saving and restoring the game save file, since ctime
> couldn't be set without either changing the system clock or directly
> accessing the file system (or kernel memory) and messing with the
> on-disk inode directly.

I had great fun with Rogue when symlinks were invented :-)

-- Dave

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]

I would take that IF clause to mean
If ICHG SET then exhibit new behavior and create now means change for ctime
field
otherwise follow original logic of ctime as being original epoch  creation
date.

Ie both behaviors are supported and depend on a flag bit being set or
cleared

On Tue, Mar 11, 2025, 11:57 PM Warner Losh <imp@bsdimp.com> wrote:

> So I think  I have to disagree about what it means in v7, comments
> notwithstanding.
>
> iupdat() has:
>                 if(ip->i_flag&ICHG)
>                         dp->di_ctime = time;
>
> ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few others,
> this was a quick peek).
>
> So even in v7, ctime means any changes to metadata / inode data. At least
> for some definition of "any".
>
> Btw, it looks like this was named IUPD in v6 and did similar things. In v6
> it is updated in iput when IUPD is set. But it looks like ctime and mtime
> are folded together. So v7 is the first edition that has ctime and the code
> implements any change to metadata from my reading.
>
> Warner
>
> On Tue, Mar 11, 2025 at 8:19 PM Theodore Ts'o <tytso@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?
>>
>>                                         - Ted
>>
>

[-- Attachment #2: Type: text/html, Size: 3582 bytes --]

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[Dan Cross]

On Tue, Mar 11, 2025 at 11:47 PM Warner Losh <imp@bsdimp.com> wrote:
> So I think  I have to disagree about what it means in v7, comments notwithstanding.

I'm not sure which part you're disagreeing with; I think Ted had it
right. The comment is just wrong, but that's what he said, if I
understood correctly.

> iupdat() has:
>                 if(ip->i_flag&ICHG)
>                         dp->di_ctime = time;
>
> ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few others, this was a quick peek).
>
> So even in v7, ctime means any changes to metadata / inode data. At least for some definition of "any".
>
> Btw, it looks like this was named IUPD in v6 and did similar things. In v6 it is updated in iput when IUPD is set. But it looks like ctime and mtime are folded together. So v7 is the first edition that has ctime and the code implements any change to metadata from my reading.

In both 6th and 7th edition (and later? Certainly into early BSD),
IUPD governs updates to mtime. 6th Edition doesn't have ctime at all,
and uses mtime for everything that the combination of mtime and ctime
is used for in later systems (modulo things only added later, of
course). I'd rephrase what you wrote as saying that what mtime
represented in the 6th edition is split between ctime and mtime in 7th
edition and later; IUPD is retained but is specific to updating the
file contents, while ICHG represents any change to the file, whether
contents or metadata.

        - Dan C.

> On Tue, Mar 11, 2025 at 8:19 PM Theodore Ts'o <tytso@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?
>>
>>                                         - Ted

[TUHS] Re: When/how did ctime change from inode "creation" to "change" time?

[segaloco via TUHS]

On Wednesday, March 12th, 2025 at 2:32 PM, Dan Cross <crossd@gmail.com> wrote:

> On Tue, Mar 11, 2025 at 11:47 PM Warner Losh imp@bsdimp.com wrote:
> 
> > So I think I have to disagree about what it means in v7, comments notwithstanding.
> 
> 
> I'm not sure which part you're disagreeing with; I think Ted had it
> right. The comment is just wrong, but that's what he said, if I
> understood correctly.
> 
> > iupdat() has:
> > if(ip->i_flag&ICHG)
> > dp->di_ctime = time;
> > 
> > ICHG is set in unlink(), chmod(), chown() and utime() (maybe a few others, this was a quick peek).
> > 
> > So even in v7, ctime means any changes to metadata / inode data. At least for some definition of "any".
> > 
> > Btw, it looks like this was named IUPD in v6 and did similar things. In v6 it is updated in iput when IUPD is set. But it looks like ctime and mtime are folded together. So v7 is the first edition that has ctime and the code implements any change to metadata from my reading.
> 
> 
> In both 6th and 7th edition (and later? Certainly into early BSD),
> IUPD governs updates to mtime. 6th Edition doesn't have ctime at all,
> and uses mtime for everything that the combination of mtime and ctime
> is used for in later systems (modulo things only added later, of
> course). I'd rephrase what you wrote as saying that what mtime
> represented in the 6th edition is split between ctime and mtime in 7th
> edition and later; IUPD is retained but is specific to updating the
> file contents, while ICHG represents any change to the file, whether
> contents or metadata.
> 
> - Dan C.
> 
> > On Tue, Mar 11, 2025 at 8:19 PM Theodore Ts'o tytso@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?
> > > 
> > > - Ted

For the record the dinode structure still exists in a header as of "SVR5" aka
UnixWare, although it is renamed "xxdinode" and lives with several other "xx"
things, so presumably just old stuff lying around.  The comment is still the
same, "time created".  There is also a larger inode structure also in an "xx"
file which instead lists "last inode change time".  Finally it looks like SCO
may have paved over all of this with their own headers, you've got an
"sco_st_stat32" struct with st_ctime and a comment of
"time of last file status change".

The current illumos sources contain an "icommon" structure in which the ic_ctime
member is commented "last time inode changed".

All that to say it looks like the commentary eventually gets cleaned up in the
SysV lineage but the old commentary persists up to SVR4 where it can be found in
/usr/src/uts/<arch>/sys/fs/s5ino.h

Needless to say, in iupdat() this appears to consistently be set based on ICHG
across these versions so the intention was probably the same all along.

- Matt G.