Hmm. rename(2) updates ctime in both BSD and Linux, but not in POSIX, and therefore not in OSX. Interesting trivial fact.
Of course, the One True Unix (v7) didn't have rename(2), but did it with a link/unlink step (which wasn't atomic, and could lead to breakage, and couldn't be done for directories except by root). And thus, ctime was updated for "renaming" even for the One True Unix.
Hence, I believe the POSIX spec is off base here, because it reflects neither classic Unix, nor current practices. It seems rather arbitrary.
As I understand it, the aim of POSIX is not to cast into stone the current set of practices, but to recommend some practices believed to be better. In the rename(2) case, I can't judge, because I don't know in which cases POSIX recommends to update ctime. (Does owner change updates ctime for example ?)
Re:ctime
Dom2 on 2003-10-22T18:33:34
I think of ctime as "inode change time". So to my line of thinking, rename shouldn't update the ctime, because the inode is not being affected, only the directory entries that point to it.Of course I'd need to look at kernel source to assert this, and that's hard work for me...
-Dom
Re:ctime
jhi on 2003-10-23T06:52:34
Note that these days POSIX and the Single UNIX Specification are the same thing.
According to SUS (available at www.opengroup.org for free, just registration needed):
- chmod, chown: update ctime
- read: updates atime
- open/O_TRUNC, rename, truncate, write: update ctime and mtime
- link: update ctime, and the ctime and mtime of the directory
- unlink: update ctime and mtime of the directory
- mkdir, mkfifo, mknod, open/O_CREAT: update atime, ctime, mtime, and ctime and mtime of the directory
- utime: update atime, ctime, and mtime
