[rescue] next up, how to read old tape of unknown format

[Dennis Boone]

> So, how do I read them and make sure I've gotten all of the data off?

A few ground rules -

1. Assume that the DDS drive is going to chew up the tapes.  They seem
to have a shelf life of about five minutes.  Get a few scratch tapes for
testing before you endanger your data.

2. Assume that the little rubber bands in the tapes will be problematic.
Sometimes they're ok, other times they're broken, sticky, or warped.
There's been discussion on cctalk about some possible substitutes.

3. DO NOT EVEN THINK about using dd to image the tape.  It discards key
info (tape block size, which may be variable).  Instead, use a utility
and output format which preserves that data.  It may not be relevant, at
which point you have some easily ignored extra data.  Or it may be
critical.  I suggest something like tapeutils for this purpose.
(https://github.com/brouhaha/tapeutils)

4. Assume you only get one or two read passes.

5. Keep going until you get nothing but errors.

> And once the data is copied, is there a self-evident way to figure out
> what's a set of boot blocks and what's a tarfile, etc?

Try feeding the data to various utilities.  Examine hex dumps.  Use the
file utility.

Doug's comment about two file marks usually meaning EOT is mostly
correct, especially for stuff Sun people do/did.  I _have_ met formats
that used two file marks to separate logical saves.

For the simh/e11 .tap format(s), it's possible to write trivial little
programs that read the tape image and emit the actual tape data to
stdout, so you can pipe that to some other utility.

De