Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!comp.vuw.ac.nz!am.dsir.govt.nz!tui.marcam.dsir.govt.nz!tony
From: tony@tui.marcam.dsir.govt.nz (Tony Cooper)
Newsgroups: comp.unix.aux
Subject: Re: Copying file systems
Message-ID: <1991May28.122741.2230@am.dsir.govt.nz>
Date: 28 May 91 12:27:41 GMT
Article-I.D.: am.1991May28.122741.2230
References: <5438@dftsrv.gsfc.nasa.gov>
Sender: news@am.dsir.govt.nz
Reply-To: sramtrc@albert.dsir.govt.nz
Organization: Applied Mathematics Group D.S.I.R.
Lines: 26


|> 	1. This method, more specifically restore (I think) had trouble
|> 	   "copying" named pipes. In my configuration there were only
|> 	   2 (lib/cron/FIFO and lpd/AppleTalk/pipe) and after the dump/restore
|> 	   I simply copied them over... restore said something about an
|> 	   "unknown mode 010xxx" where xxx was either 660 or 666.
|> 
|> 	2. All symbolic links were (re-)created with an owner and group of
|> 	   root. Of course, this really doesn't matter, since the owner, group
|> 	   and mode of a link doesn't mean all that much, but it still is
|> 	   a change over what the file-system looked like before...
|> 
These aren't flaws with the dump method. They are BUGS with the dump and
restore programs. Better read up on that SPR stuff.

Thanks for pointing this out. I`ll include this information in my Tips, Tricks,
and Hints compilation.

For readers: trivial bugs like these aren't too trivial to post in this
newsgroup (in my opinion). Or to send to me for my compilation. Somewhere,
sometime, when you least expect it, you are going to be hit by something
trivial like this.

Tony Cooper
sramtrc@albert.dsir.govt.nz <- the address to send your tips, tricks,
			       hints, and spare CDROM drives.