On Mon, Feb 13, 2006 at 01:58:09PM -0800, Kevin Till wrote:
> Josef Wolf wrote:

> >>1. VOL05:1 (this is the newest non-broken available dump) is _not_
> >>  considered for retrieval at all.
> >>
> >>2. Instead, amfetchdump _tries_ to get the (broken) VOL04:7.
> >>
> >>3. But instead of VOL04:7 it gets the (older) VOL04:1.  There seems to be
> >>  no attempt to further search for VOL04:7
> >>
> >>4. The order of tapes seems to be wired.  I would have expected
> >>     VOL05 VOL02 VOL03 VOL10         (how they were sceduled)
> >>  or VOL05 VOL04 VOL10               (last available for every dumpdate)
> >>  or VOL05 VOL10 VOL01 VOL08 VOL09   (first available for every dumpdate)
> >>  or some such.
> >>
> >>5. When trying to append the second chunk to the first one, amfetchdump
> >>  fails with "Bad file descriptor".  The resulting dump (uncompressed)
> >>  is 527620009 bytes long.
> >>
> >>6. Next problem is with amrecover, but it seems to be closely related 
> >>  with the "Bad file descriptor" problem.  Unfortunately, I don't have a
> >>  transcript for this problem, because the system crashed.  Here's the
> >>  description:
> >>
> >>  When I tried to retrieve the above mentioned DLE mentioned in line c
> >>  with amrecover, the system (Athlon 1800+, 500MB RAM, 2G swap,
> >>  suse-10.0) freezed, but vterm switching and pinging from a different
> >>  host worked.  This reminds me of overcommitments caused by memory-hogs.
> >>
> >>  After reboot, I noticed following file in the slot-directory
> >>  of the vtape directory:
> >>
> >>   -rw-------   1 amanda disk 527630347 Feb  7 07:52 info
> >>
> >>  Notice that the length is almost the same as in 5. This file starts with
> >>  following contents:
> 
> can you make sure you have restore-src/restore.c revision 1.19 or above?
> One fix went it on r1.19 which resolved one file descriptor problem.

Thanks Kevin!

I have tried with newest (1.23) restore-src/restore.c.  With this, bullet 5
seems to be gone.  Bullet 6 don't crash the system anymore, but still don't
seem to work properly:

   Extracting files using tape drive changer on host host.do.main.
   Load tape VOL01 now
   Continue [?/Y/n/s/t]?
   The following tapes are needed: VOL01
   amrecover: short block 0 bytes
   UNKNOWN file
   amrecover: Can't read file header
   amrecover: Extractor child exited with status 1
   
   extract_list - child returned non-zero status: 1
   Continue [?/Y/n/r]?

The other issues (1..4) are (of course) still present.