Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!umd5!eneevax!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: 4.3BSD rename() changes ctime
Keywords: ctime dump rename
Message-ID: <12865@mimsy.UUCP>
Date: 5 Aug 88 22:57:55 GMT
References: <26657@oliveb.olivetti.com> <2167@pixar.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 28

In article <2167@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes:
>In the case of "rename", the file's name has changed; thus the file has
>changed in some way, and that fact must be recorded by /etc/dump.

This is true.  Both you and Griff Smith (and undoubtedly many others)
have reached the wrong conclusion from this fact, however, at least if
the backups are to be done by `dump'.  (In another program you would be
right.)

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.  The file's inode number has not changed, nor has
any of the information in the inode, nor its data; it need not be
dumped at all.  Only the change of name must be recorded, and it is
implicit in the fact that some directory no longer has that <name,ino>
pair, and another directory (possibly the same) now has a new
<name,ino> pair.

Whether restore would in fact correctly restore such a change is
another matter: since dump *does* write the file, restore can get away
with assuming it.

Other backup programs (tar certainly, cpio perhaps) do not write
directory data blocks, depending instead on later path name information
to imply the directory contents.  Here the file must indeed be dumped.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris