4.3BSD rename() changes ctime

[Don Speck]

In article <7660 at cit-vax.Caltech.Edu> I wrote:
> 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,

In article <23338 at labrea.Stanford.EDU>, karish at denali.stanford.edu (Chuck Karish) writes:
>							What if I rename
> a file, run tar or cpio, then remove the first link to the file?
> The file isn't present on disk, and it's not present on the backup.

The reason it's not on that backup is that its ctime is old.  Thus,
it must have existed at the time of the *previous* backup.  Restore
the previous backup first, rename the file, and restore the current
incremental backup.  You already have to do manual rename/rm/rmdir
when restoring tar or cpio incremental backups, since tar and cpio
don't carry enough information to do this for you.

If you renamed the directory containing the file, or a symbolic link
pointing to the file, instead of the file itself, the ctime of the file
would not be updated on any Unix, and so the file, though it effectively
has been renamed, wouldn't appear on your incremental backup.  The
ctime is not a reliable indicator that the file's name(s) have changed.

>					tar uses it [the link count] to
> solve the problem you pointed out before: resolving multiple file names
> that refer to the same data (when both links are being saved).

The  inode number  is used to determine which files are linked.
To save memory, tar doesn't remember the inode number if the
link count is 1; but without link counts it all still works.
A link count greater than 1 doesn't even mean that tar will
necessarily encounter any other links.

I reiterate that the link count is a convenience for garbage
collection, it's not essential for anything else (most filesystems,
such as VMS's, don't even have them).  You could set all the link
counts to MAXINT and everything should continue to work until you
run out of disk space.

Changes in the link count ought not change ctime, just as
renaming the containing directory does not, even though both
actions change one or more of the file's names.  The name(s)
(the links) are not part of the inode; the link count should
be classed with the links.  Would this be more clear if the
link count had been stored elsewhere, analogous to the inode
allocation bitmap of some filesystems?

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