Subject: Re: restore dumps core on different filesystems
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: James Graham - Systems Anarchist <greywolf@starwolf.com>
List: current-users
Date: 07/08/1996 18:45:20
Jason Thorpe sez:
/*
* Define "non-native". Do you mean "A UFS filesystem not created with
* NetBSD" or "A non-FFS filesystem, such as NFS". From your previous, it
* seemed to me like you were saying
I mean the dump was created from SunOS., and Yes, I was attempting, precisely,
the following:
* cd /some/nfs/filesystem
* restore ivfb /dev/nrst1 112
*
* ...and I was saying "I don't think that was ever intended to work."
What do you *mean*, "I don't think that was ever intended to work."? I'm
RESTORING onto a filesystem, not DUMPING from it. I would expect certain
things to break on a restore from a UFS dump onto, say, a MS-LOSS file-
system (fifos, devs), but I will still be shocked if it comes back and
says 'Segmentation violation', while it doesn't do that if $CWD is
local/FFS.
What you seem to be telling me is that 'restore i' can be expected to break
if run with an NFS point as the current working directory.
That's *never* been true. I can do that under SunOS all the time.
I should at least expect restore not to segv before it reads the table
of contents. Currently, this is just what is happening. Which, to me,
means that this is something which a) should have been discovered ages
ago, and b) should have been fixed at that same ages ago, and c) most
certainly should NOT be manifesting itself at this point in time.
"Segmentation faults. HEH! Data alignment errors. HEH! A robust UNIX-
alike system craves not these things. YOU ARE RECKLESS!"
*
* Now, it's possible that that's not at all what you were describing :-)
*
*/
[Take my apparent emotions with a grain of salt -- I'm more astounded than
anything.]
--*greywolf;
--
America is quite possibly the only country to go from barbarism to
decadence without the requisite intervening period of civilisation.