4.3BSD rename() changes ctime

[Chuck Karish]

In article <7660 at cit-vax.Caltech.Edu> mangler at cit-vax.Caltech.Edu (Don Speck) writes:
>In article <12865 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
>So why have changes in
>the link count affected the ctime in *any* version of Unix?

ctime records the last modification time of the inode.  This
information is useful for some programs; others may ignore it.

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

I disagree.  If tar or cpio were smart enough to do this, it'd be
impossible to predict what files would be backed up.  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.

Anyway, how do you propose that tar or cpio discover that a file has been
renamed?

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

I guess this is right, as long as the link count is 1 and it's not
looking through a symbolic link.  Checking ctime is still the easiest
way to check that the file hasn't been fooled with.

>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.

The link count is an attribute of the object we call an inode.  It's
useful for more than garbage collection.  For example, tar uses it to
solve the problem you pointed out before: resolving multiple file names
that refer to the same data (when both links are being saved).  This
feature would be useful on a write-once filesystem.

Chuck Karish	ARPA:	karish at denali.stanford.edu
		BITNET:	karish%denali at forsythe.stanford.edu
		UUCP:	{decvax,hplabs!hpda}!mindcrf!karish
		USPS:	1825 California St. #5   Mountain View, CA 94041