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