4.3BSD rename() changes ctime

[Rick Ace]

In article <26657 at oliveb.olivetti.com>, jerry at olivey.olivetti.com (Jerry Aguirre) writes:
> Prior to the "rename" system call the mv command would change the ctime
> of a file even though the resulting data AND inode were identical.  This
> was an anavoidable consequence of the link and unlink process used to
> implement renaming.
> 
> Well, now that we have rename, it still does!  It doesn't seem right
> that a system call that doesn't change the inode or the data in the file
> should result in the file being dumped in the next backup.
> 
> Is this a bug or is there some justification for rename updating the
> ctime?

The principal purpose of the ctime field in the I-node is to alert
/etc/dump that the file has changed in *some way* and must be backed up.
In the case of "rename", the file's name has changed; thus the file has
changed in some way, and that fact must be recorded by /etc/dump.

When performing a non-level-0 dump, /etc/dump uses the ctime field in its
decision to determine whether or not to select a file for backup.
If anything about a file changes (mode, nlinks, data contents, name, etc.),
then that must be noted on a dump tape.  Unfortunately, /etc/dump operates
on an "all or nothing" basis, so in this case you pay the price of
backing up both the I-node's contents and the file's data just to record
the fact that the name alone changed.  (Indeed, there is not enough
information in the I-node for /etc/dump to distinguish between cases
where the file's data has changed and when only an I-node field has.)

Rick Ace
Pixar
3240 Kerner Blvd
San Rafael CA 94901
...!{sun,ucbvax}!pixar!rta