4.3BSD rename() changes ctime

[Don Speck]

In article <12865 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> Since the parent directory(ies) of the file that was renamed were
> altered, dump will save them regardless of any changes to that file.
> This is both necessary and sufficient for restore to figure out that
> the file was renamed.

This should be true regardless of whether the rename was accomplished
by the rename() call, or by link()/unlink().  So why have changes in
the link count affected the ctime in *any* version of Unix?

Tar and cpio backups, which don't account for renaming, would be better
off NOT backing up renamed files, so that when you restore a series of
such backups you get only one copy of the file, rather than one in the
old location and one in the new, overflowing the filesystem.  (Tar and
cpio have serious problems as backup tools in any case).

Rogue shouldn't care about renames when determining whether a saved game
is the original copy.

I claim that things would work better all around if changes in the link
count did NOT update the ctime.  The link count is not an attribute of the
object we call a file, it is a convenience to simplify garbage collection.
On a write-once filesystem you wouldn't even want link counts.

Don Speck   speck at vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck