[BUG][Unix] ctime and mtime entries swapped in DirectoryEntry

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Oct 24 00:41:05 UTC 2003


Alexander =?iso-8859-2?q?Lazarevi=E6?= <Alexander at Lazarevic.de> asked:
	Is the ctime changed if a file is opened for write?
	I thought it just gets updated if the metadata changes?
	This is what I would read out of the gnu libc documentation.
	
Here's the relevant text from the Solaris 2.9 stat(2) manual page:

     st_atime
	  Time when file data was last accessed.  Changed by the following
	  functions: creat(), mknod(), pipe(), utime(2), and read(2).

     st_mtime
	  Time when data was last modified.  Changed by the following
	  functions:  creat(), mknod(), pipe(), utime(), and write(2).

     st_ctime
	  Time when file status was last changed.  Changed by the following
	  functions:  chmod(), chown(), creat(), link(2), mknod(), pipe(),
	  unlink(2), utime(), and write().

Note that it is not *open()* for write that matters but each actual
*write()*.  Since st_mtime is part of the metadata, it is necessarily
the case that each update to st_mtime implies a corresponding update to
st_ctime.  Since write() updates st_mtime, write() should update st_ctime.
Similarly, read() updates st_atime, which is part of the metadata, so it
has to update st_ctime as well.

My copy of POSIX.1 seems to have "walked".  Whoever took it kindly left
my copy of the trial-use version, which recommended that 
    st_atime should be updated by
	creat(), lock(), mkdir(), mkfifo(), utime(), and read().
	["mknod()" in Solaris implies mkdir(), mkfifo()]
    st_mtime should be updated by
	creat(), mkdir(), mkfifo(), utime(), and write()
    st_ctime should be updated by
	chmod(), chown(), creat(), link(), mkdir(), mkfifo(), pipe(),
	read(), remove(), unlink(), utime(), write().

It would have been nice if st_ctime had only noticed changes that were NOT
noticed by st_atime or st_mtime, but that's not what the specifications say.

There's some weasel-wording about just _when_ the file times are updated
so than an operating system doesn't have to do an inode write for every data
read(). You get phrasing like "Upon successful completion, where nbyte is
greater than 0, read() will mark for update the st_atime field of the file",
where "mark for update" means that the OS will get around to doing something
about it later, but maybe not just yet.

So st_atime => approximately when the file was last created, locked, or read;
   st_mtime => approximately when the file was lasted created or written;
   st_ctime => approximately when the file was last touched at all.




More information about the Squeak-dev mailing list