On Fri, Mar 29, 2002 at 08:54:11AM -0500, Joshua Baker-LePain wrote: > On Thu, 28 Mar 2002 at 7:20pm, Andy Zhang wrote > > > So, basically, a file looked like '74550524305 7550414032 /./scripts/driver' > > Each file has this preceeding directory. It's hard, if not impossible to > > access these directories to retrieve the files that I > > wanted. I tried not to '| tar xvf -', instead '> tarfile', and it still > > showed the same results by viewing the tarfile through 'tar -tvf'. > *snip* > > > - both are using Gnu-tar, downloaded the source, and compiled on the > > server/client. > > Sounds like a bad version of tar -- 1.13. You need to get at least > 1.13.19 or 1.13.25 from alpha.gnu.org and use one of those.
On my Solaris tape host I have tar (from sun), gtar (1.13.whoknows that I have to leave alone), and "amgtar" (my installed version of 1.13.25, just for amanda). I was recovering a file from a remote client on the tape host, manually, not using amrecover. I blindly stuck gtar, the bad version, in the pipeline. When it gave results like Andy Zhang got "745505..." I thought 'SH**' the client still has a bad tar. But the client was using 1.13.25. Then I remembered my good, "amgtar" and the recovery went fine. Points to be made: a bad gtar can't even read good tapes. Maybe even bad gtar's write good tapes, but can't read them. Don't chuck your "bad tapes" until you try to read with a good gtar. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
