Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: comp.unix.wizards
Subject: Re: 4.3BSD rename() changes ctime
Summary: why should link/unlink change ctime?
Keywords: ctime dump rename
Message-ID: <7660@cit-vax.Caltech.Edu>
Date: 22 Aug 88 08:27:46 GMT
References: <26657@oliveb.olivetti.com> <2167@pixar.UUCP> <12865@mimsy.UUCP>
Organization: California Institute of Technology
Lines: 25

In article <12865@mimsy.UUCP>, chris@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@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck