On Mon, May 02, 2005 at 12:08:08PM +0100, gj enlightened us:
> I finally have some more clarifying(?) details of my problem(s) that some of 
> you
> were asking for!
> 
> The amrecover error I am writing about in this email is slightly different 
> from
> the problem in my original post, but perhaps they are related? When I try and
> add/extract a file in amrecover (which I can see with "ls" in amrecover), I
> sometimes get:
> ------------
> EOF, check amidxtaped.<timestamp>.debug file on localhost.
> amrecover: short block 0 bytes
> UNKNOWN file
> amrecover: Can't read file header
> extract_list - child returned non-zero status: 1
> ------------
> 
> I've checked the index files for that backup dump date, and the file I'm 
> trying
> to extract is listed in the index (which makes sense, I suppose, seeing as 
> "ls"
> gives me the file, and I assume "ls" in amrecover is based on these index
> files). I've made sure I've loaded the right virtual tape as well.
> 

------------< snip <------< snip <------< snip <------------

> 
> The thing is, I also have another machine listed in the "FAILURE..." as "dump 
> to
> tape failed" as well as a retrying attempt in the "NOTES" section, but I can
> still recover the files off this machine!! So I'm not sure exactly how I 
> interpret these reports and where things may be going wrong. Is this related 
> to
> the 1.13.93 gnutar version I have?
> 

Yes, 1.13.93 is known to (usually) create bad indexes. Go back to 1.13.25
and all should be well. 

Matt

-- 
Matt Hyclak
Department of Mathematics 
Department of Social Work
Ohio University
(740) 593-1263

pgpa8HFNj1mvS.pgp
Description: PGP signature