Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!uw-entropy!thebes!campbell
From: campbell@Thalatta.COM (Bill Campbell)
Newsgroups: comp.unix.xenix
Subject: Re: Backing up hard disk for transfer to new disk.
Message-ID: <3406@thebes.Thalatta.COM>
Date: 2 Apr 90 03:15:39 GMT
References: <3714NU013809@NDSUVM1> <644@bbxsda.UUCP>
Reply-To: campbell@Thalatta.COM (Bill Campbell)
Organization: Thalatta Corporation, Bellevue WA
Lines: 32

In article <644@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>In article <3714NU013809@NDSUVM1> NU013809@NDSUVM1.BITNET (Greg Wettstein) writes:
>>My question is basically: What is the best utility/procedure to use so that
>>the contents of the 80 megabyte drive can be transfered to the 330 megabyte
>>drive with a minimum of system disruption?
>>
>I strongly advise that you use cpio instead of tar.  tar will not preserve
>directory owners and permissions.  Also, tar does not handle device files
>very well (cpio will).
>
cpio has its own set of problems, particularly if you have large linked
files (it makes a copy for each link).
I have gotten around this by creating a regular file with cpio containing
information on everything that is *NOT A FILE* i.e.:
	find . \! -type f -print | cpio -ocv > /tmp/devcpio
then dumping this as the first file on the tar tape (you may also compress
if you like).

I then tar the /tmp/devcpio file off by itself and run:
	cpio -icvmd < /tmp/devcpio
(after cd'ing to the correct directory of course).  This not only
recreates directories properly, but will also create the appropriate
device entries if necessary.

Tar seems to be somewhat more robust (at least on Xenix systems) than
cpio.  EXCEPTION*** NCR Tower UNIX implementations of tar have been
very buggy in my experience.
-- 
....microsoft--\					Bill Campbell; Celestial Software
...uw-beaver-----!thebes!camco!bill	6641 East Mercer Way
....fluke------/					Mercer Island, Wa 98040
....hplsla----/						(206) 232-4164