How do I read a bad tape (tar)?

[Dave Olson]

In <1991Apr9.225311.6534 at lokkur.dexter.mi.us> scs at lokkur.dexter.mi.us (Steve Simmons) writes:

| olson at anchor.esd.sgi.com (Dave Olson) writes:
| >Unless you are getting kernel messages on the console or in SYSLOG, odds
| >are VERY high that someone overwrote the beginning of the tape, perhaps
| >by doing a 'tar c' with no args (fixed in the next release to be a
| >no op, instead of trashing the tape), when they meant 'tar t'.
| 
| >If so, there is no hope.  The firmware on the drives refuse to read
| >past the EOD marker.  Besides, it erased a part of each track when
| >the the 'tar c', or whatever was done.  This is one of thoese FAQ
| >that shows up in all the comp groups from time to time.  Remember,
| >the write protect switch is your friend!
| 
| 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

Bzzt.  Sorry, you are wrong,  An EOD marker on non-9track drives is
NOT two filemarks.  It is a specific set of information in the block headers
that tells the drive that EOD has been reached.  I haven't yet found a
SCSI QIC drive that can be tricked into skipping past it.

The '2 FMs means EOD' is just a convention on 9 track drives, and there
is nothing special about 2 FM's in a row, as far as the drive is concerned.
Many device drivers treat it specially, but that is a different issue
altogether.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.