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