4.3BSD rename() changes ctime

[Gary Allen]

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?

Consider the command 'mv foo bar'. Before issuing this command, there is
a file called 'foo' and (usually) no file called 'bar'. After issuing
this command, the exact opposite is true. Since there was no such file
as 'bar' before, it is certainly logically altered by creation even
though technically neither the inode nor the disk blocks of the file
have been. Logically at least, 'mv foo bar' is the same as
'cp foo bar; rm foo'.

The directory itself is certainly altered so that must be backed up,
(which effectively deletes 'foo') and 'bar' is a file that never existed
before so it must obviously be backed up.

Caveat: this is merely my assumption of how it should work. I didn't
look at how dump actually works. It's certainly possible to be more clever
just to handle the case of renamed files but that seems a fair amount
of trouble for not a lot.

Gary Allen
Apollo Computer
Chelmsford, MA
{decvax,yale,umix}!apollo!gallen