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
pgplVPAjLabgI.pgp
Description: PGP signature
