Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!ltuxa!ttrdc!ttrda!dwd
From: dwd@ttrda.UUCP (Dave Dykstra )
Newsgroups: net.bugs.usg
Subject: Re: Some thoughts on enhancing cpio(1)
Message-ID: <153@ttrda.UUCP>
Date: Mon, 12-May-86 13:45:37 EDT
Article-I.D.: ttrda.153
Posted: Mon May 12 13:45:37 1986
Date-Received: Tue, 13-May-86 09:09:56 EDT
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 46

In response to the two articles by Mark Brukhartz:

> ... the rename problem is deeper than inferred; what about all of
> the file pathnames which change when a directory is renamed?

> Incrementals appear safe as long as you compare reality to a list of full
> pathnames and inode change times from a full backup. Kept ordered by path,
> it's easy to generate a list of deleted, added and changed files. Even the
> directory-rename case (mentioned above) is handled reasonably well; every
> file in the tree is noted "deleted" with the old name and "added" with the
> new name.

Yes, I overlooked the possibility of renamed directories.  Your scheme
of keeping a sorted list of paths sounds like the best solution.

> Directories are recursive. A change to the root directory would turn the
> next incremental backup into a full one. When "filehog" removes the vnews
> core file from his home directory (:-), all of his files will be backed
> up again. Ugh!

I don't understand that.  Changing a directory doesn't require a back up
of all subdirectories, only if the name is changed.

Now, about removing missing files.  Mark writes about this possibility:

>	o Assume that nonexistent files are intended to be removed. This
>	  sounds dangerous... It's too easy for a mortal user to "backup"
>	  and "restore" a mode 777 directory containing inaccessible mode
>	  400 files, inadvertently removing the files. Yes, it's possible
>	  to distinguish "no permission" from "no such file" errors, but
>	  the possibility for bugs and other problems is disturbing.
>
>	o Add a "key" as the first character of each input pathname, with
>	  ">" meaning "copy" and "<" meaning "remove". This would have to
>	  be Yet-Another-Option* to preserve what little cpio invocation
>	  compatibility remains. Consider, too, of all of the other keys
>	  which could be added by future featurefesters (...say that five
>	  times quickly!).

I'm assuming that the backup and restore will be done by root so there
will be no problem with inaccessible files.  It sounds like an easier
solution than the "key" idea; a separate program would need to be written
to put in the keys.

					- Dave Dykstra
					  ihnp4!ttrdc!ttrda!dwd