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: -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

On Tue, Mar 11, 2025 at 08:02:19PM -0700, Rik Farrow 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. 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. 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

On Wed, 12 Mar 2025, Theodore Ts'o wrote: I had great fun with Rogue when symlinks were invented :-) -- Dave

On Wed, Mar 12, 2025 at 01:33:14PM +1100, Dave Horsfall wrote: 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

On Tue, Mar 11, 2025 at 09:38:39PM -0600, Warner Losh wrote: 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

Rob Pike <robpike(a)gmail.com> wrote: 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

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(a)bsdimp.com> wrote:

On Wednesday, March 12th, 2025 at 2:32 PM, Dan Cross &lt;crossd(a)gmail.com&gt; wrote: 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.