Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ctime (Score:5, Insightful)

    Interestingly, perl internally performs the link/unlink step on platforms where rename isn't available. (They must not be very common nowadays.)

    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 ?)

    • 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

      • Note that these days POSIX and the Single UNIX Specification are the same thing.

        According to SUS (available [unix-systems.org] 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, ct