Reading past EOT on a cart tape

[AI.CLIVE@MCC.COM (Clive Dawson)]

We had a disk crash on our main LispM fileserver over the weekend.
In the process of restoring from our LMFS dump tapes after the
disk was replaced, we found a problem on one of our incremental
dump tapes, which has some critical files.

When trying to restore or list from that tape, the system reports
that it does not appear to be a LMFS dump tape.  We examined the
tape more carefully with a small program to read the raw data, and
discovered that the first thing on the tape was a message of the
form "Error        File aborted", followed by the last few files
of our incremental dump.  The entire first part of the dump seemed
to be missing.

We were able to reconstruct a possible scenario to explain how this
happened.  If the cart is removed from the drive during a dump,
and then re-inserted, an error will pop up on the Lispm saying there
is no tape in the drive.  If you resume from this error, erroneously
expecting things to proceed normally, you lose.  The tape will first
rewind.  This appears to be what happened in our case.  It is safe
to say that the bulk of the files we need are on the tape, following
the end-of-file mark(s) that were written at the conclusion of the
incremental dump.

Now to the problem at hand:  How can we recover most of the files?
I have tried innumerable ways to get the LispM to read past what
it thinks is the end-of-tape.  There is a variable in Reloader.Lisp
which explicitly allows for this:  *reloader-query-about-true-EOT*
which was apparently designed for this purpose.  We can't get it
to work in this case.  The tape just spins forward a couple of inches
then back, then forward, etc., forever, each time reporting an EOF,
but apparently not being able to get past it.

I tried several experiments on a scratch tape in which I would write a
few records and physically remove the cart tape from the drive so that
it wouldn't write an EOF.  (I was prepared to write a dummy file at
the beginning of the dump tape to try and erase the EOT, if
necessary.)  This wasn't good enough.  The software (or microcode)
still cannot read past a spot where the last write took place.

I am now seriously considering removing the cabinet from a cart drive,
allowing me to try and physically advance the tape a few inches
without triggering the "tape out of drive" error, which will of
course cause rewind when the tape is reinserted.

Does anybody have any better suggestions for getting at the data
after an EOT???

Many thanks,

Clive Dawson
MCC
Austin, Texas
-------