Xref: utzoo comp.unix.admin:1549 comp.sys.sgi:9367
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!stanford.edu!leland.Stanford.EDU!elaine19.Stanford.EDU!dhinds
From: dhinds@elaine19.Stanford.EDU (David Hinds)
Newsgroups: comp.unix.admin,comp.sys.sgi
Subject: Re: How do I read a bad tape (tar)?
Keywords: tar tape sgi unix
Message-ID: <1991Apr10.004953.17211@leland.Stanford.EDU>
Date: 10 Apr 91 00:49:53 GMT
References: <1991Apr8.231456.391@gpu.utcs.utoronto.ca> <1991Apr9.030501.23536@odin.corp.sgi.com> <1991Apr9.225311.6534@lokkur.dexter.mi.us>
Sender: news@leland.Stanford.EDU (Mr News)
Organization: Stanford University - AIR
Lines: 23

In article <1991Apr9.225311.6534@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes:
>olson@anchor.esd.sgi.com (Dave Olson) writes:
>
>Hmmm...some help might be possible here.  First, one needs to trick
>the drive into reading past the EOT (not EOD) marker.  This *can* be
>done with some drives (I've done it), as long as one is careful.  An
>EOT marker is two tape marks.  So *if* the conjecture about a small
>tar blotzing the head of a large one is true, one could do so by doing
>
>   mt -f <no_rewind_tape> fsf 1 ; mt -f <no_rewind_tape> fsf 1
>
>Now the tape is positioned past the EOT mark.  Use GNU tar to read the
>damaged data.

    I didn't realize you could just step past the tape marks like this.
What I've done before, to get past an EOD, is to rewrite another small
archive over the one causing the problem, but then eject the tape from
the drive before it writes its EOD.  Then, reading the tape runs into
a media error, but hopefully tar should try to resynchronize and read
the rest of the tape.

 -David Hinds
  dhinds@cb-iris.stanford.edu