From owner-freebsd-bugs  Wed Nov 15 21:59:04 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA24163
          for bugs-outgoing; Wed, 15 Nov 1995 21:59:04 -0800
Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA24146
          for <bugs@freebsd.org>; Wed, 15 Nov 1995 21:58:59 -0800
Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au 
          id <26502-0@bunyip.cc.uq.oz.au>; Thu, 16 Nov 1995 15:55:25 +1000
Received: from netfl15a.devetir.qld.gov.au 
          by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP 
          id OAA24019; Thu, 16 Nov 1995 14:48:53 +1000
Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) 
          id EAA23348; Thu, 16 Nov 1995 04:47:48 GMT
Message-Id: <199511160447.EAA23348@netfl15a.devetir.qld.gov.au>
X-Mailer: exmh version 1.6.4 10/10/95
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: bugs@freebsd.org
Subject: Re: Cannot interactively restore from a multivolume dump
In-reply-to: Your message of "Wed, 15 Nov 1995 21:55:33 +0100." <199511152055.VAA08838@uriah.heep.sax.de>
X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 
        7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! 
        >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 
        M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 16 Nov 1995 14:47:48 +1000
From: Stephen Hocking <sysseh@devetir.qld.gov.au>
Sender: owner-bugs@freebsd.org
Precedence: bulk


> I've succesfully been using it.  It's okay that it doesn't read the
> entire tape in order to find that it hasn't to deal with just that
> particular volume (that's one of the big advantages of dump/restore
> actually!).  It simply tracks all i-node numbers that it wants to
> restore, and all it has to do for any volume is to examine the first
> header on it, and see if there's any actual work on this volume.  (It
> does always write based on i-node number ordering.)
> 
> So the question is: why did it think that your files haven't been on
> *any* volume?

Don't know - I tried dumping again (this time making sure that the fs was unmounted, last time it was just quiescent) and then interactively restoring gain. I took note of where the inodes started from for each tape (I love the scrollback on xterm) and when I did the interactive restore, chose the tape dependent on the inode of each file, as shown by the directory on tape 1 and  extracted. It still said "resyncing on restore, skipped 33 blocks" but found the files OK. Wish I knew why it was resyncing - I'll probably dive in with a debugger one of these days.

	Stephen
-- 

        I do not speak for the Worker's Compensation Board of Queensland -
                     They don't pay me enough for that!