Jason Thorpe writes:
>> [ message about trying to restore when cwd == NFS volume deleted]
> 
> 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:
> 
> 	cd /some/nfs/filesystem
> 	restore ivfb /dev/nrst1 112
> 
> ...and I was saying "I don't think that was ever intended to work."

Why not? restore just uses normal filesystem operations to create stuff;
it's only dump that "knows" about the filesystem internals.

And to prove my point, I just did something like:

	client1# cd /some/NFS/dir
	client1# touch foo.dump
	client1# dump 0f foo.dump /
		(machine has local /)

	client2# cd /some/NFS/dir
	client2# mkdir bar
	client2# cd bar
	client2# restore xf ../foo.dump

It works. Mind you, the clients were ULTRIX boxen of a Solaris 2 server,
but the version of dump and restore I used are hacked up NetBSD(*) ones.

Now, as to greywolf's problem, I have no idea. There's no explicit
reference to mmap in the restore code, so unless it's tickling a NetBSD
libc bug I'm more inclined to believe that it could be an NFS issue.
However, didn't Frank van der Linden check in a fix to NFS access times
recently (which may be of relevance since the way that permissions and
times are stored in dumps changed from the old-style used in ULTRIX,SunOS,
and other <4.4BSD systems to a different style in 4.4BSD+ systems -
something that I had to work around in the hacked version of restore
mentioned in the footnote below.

Luke.

(*) Yep, we ported NetBSD dump/restore to ULTRIX, and then ported the
    hacked restore to Solaris. That way, we can use one command for
    dump and rdump (a 4.4BSD extension I like), and we can restore
    ULTRIX filesystems on ULTRIX or Solaris (using the ported restore),
    and NetBSD (using the native restore, which can handle the older
    style filesystem dumps).