Tape dumping programs for Unix/Linux...

From: Stan Sieler <sieler_at_allegro.com>
Date: Thu May 2 17:00:10 2002

Re:
> > - ability to flag if the current tape record had a recovered read
> > error (obviously, not all hardware/OS's support getting that information)
>
> No. And I see no useful purpose in including that in the format.
> If the read was recovered, you have the data; surely you would
> *not* want to recreate a tape and make a previously marginal
> block, marginal again on a clone?


NOOOO! It's *IMPORTANT* to know if there was a question about the
accuracy of the data! That's *WHY* some tape drives even *tell*
you there was a recovered error ... so the user could use that
information!

You clearly aren't going to try to create a marginal record if/when
you recreate the tape.

You *are* going to be able to truthfully and accurately answer
questions about the validity of your tape copy .. *ONLY* if
you record that information (if it's available).

It's like getting a recovered parity error on memory.
Should you know about it? DAMN STRAIGHT YOU SHOULD!

Without recording that information, you also can't answer
important questions like: is the orginal tape in good shape?
  

> > - ability to flag if a particular tape record had a hard error
> > while reading it
>
> No (I can say this even though I'm about to ask): do you mean an
> unrecoverable error, or one that was corrected by the hardware
> (as opposed to being corrected by software)? Either way, if the
> error was corrected, see my response above.

If it was corrected, then there was no error (other than a
recovered read, already correct recorded via the earlier bit :)

I meant a real, live, actual error. (E.g., missing oxide)

When recording the contents of a tape it's **IMPORTANT** to know
that there was an error there. If you simply skip the erorr and
keep reading, you've lost data.
Did you lose original user data? Possibly, and you've definitely
lost data about the tape (i.e., the fact there was an error).

By recording the fact an error occurred, along with any data
your tape drive/OS *may* have sent you, you preserve the ability
to act wisely in the future. For example, by recording the
fact there was an error at megabyte 100 in a 102 MB file,
the user would have confidence that when that file is eventually
extracted, the first 99 MB of it is in fine shape.


> > - ability to flag if an End-of-tape marker/indicator was seen
> > while reading the the current record (again, not all
> > hardware/OS's support getting that information)
>
> No, and again, I can't see how this data would be used to recreate
> the tape or would be needed by an emulator. It's kind of like asking
> if a particular hardware emulator also emulates memory parity errors
> so that you can see memory parity errors in the logs. Why??

With 9-track tapes, software writing to the tapes generally watches
for an indication that the end-of-tape marker (a short silver
reflective strip) has been seen. At that time, it can prepare
to do a reel-switch. Although some people feel they can backspace
and write reel-switch info prior to the EOT marker on a 9-track
tape, that's technically not safe (and opens up the possibility
of getting what's called (in 1979) "crap in the gap"). Anyway,
the ANSI (?) standard for 9 track tapes specifies a minimum length
of tape be available for writing after the EOT marker ... a length
that should be sufficient (even with modest multiple outstanding
write-ahead requests) to write the reel switch information.

On at least one OS, Burroughs MCP, one could detect that EOT at
read time. Then, if one is doing multiple read-ahead requests,
one can moderate them appropriately.

Ok...the short answer: it's information. You don't throw away
information without a darn good reason. :)


> > - overall header at start of file, recording information about the tape
>
> No, although I did consider suggesting some extensions like this.
> One problem I have encountered with some old CDC tape formats

Sorry...if you want a professional program, not something like
that toy cptape, you *WILL* have this information.

Been there, worked on that, for over 30 years. Trust me...you
*want* all the information you can get.

> Anyway, I encode that kins of descriptive information (what kind
> of computer, encoding, #tracks, etc) in the filename, or in the
> name of the directory containing the file, or in a README.

If two items of data are separated, what happens to them?
Yep. Should be 'nuff said :)
 
> > I have a program called "tapedisk", which reads an arbitrary tape
>
> This sounds familiar... is it on the web somewhere?

The MPE V version was/is (can't recall which), and was free.
The MPE/iX version is a product from our company.

You might be thinking of CodeBlue's TapeDisk, a PC disk
to tape backup mechanism. (I bought a copy about 5 years
ago, but had some problems with it: it didn't work on parallel port tape
drives as implied, IIRC. Once I got a different kind of tape drive,
it seemed to work, although we never had to recover with it.)

Since my first version tapedisk preceded theirs, I don't mind calling
mine that ... at least, not until the lawyers threaten me :)
 
>
> So you really do want to recreate bad tapes as bad tapes...
>
> Why?

No...I want to know that a problem existed, and where that problem was.

Again...this is basic, vital, and indisputable. You *NEED* to
know if there was a problem with the tape, and if you're trying to
extract a particular file you need to know where any problems
are in that file. Otherwise, you'll be lying to the user.

If you know where within a file an error was found, then you've
got a chance at recovering most of the rest of the data successfully.
If you know an error occurred *somewhere* in a file, but not
where, then you have a large pile of bits which *might* be trash,
and *might* be useful ... but neither you or the user knows.
And, if you don't know where the errors were (and how many there
were), you can't reliably restore the data. That data might
be banking information that your company is being audited on;
it might be data that could clear someone of a crime...you simply
don't know.

Data is important...that's why we call it data and not junk :)

> This is some what I store as a "header" at the start of the
> > overall output:
>
> ...
>
> Yeah, this info is README fodder... why on earth program that?

Uh, 'cuz someone had to do it and build a reliable, thorough
program?


> > As you can see...a lot of info, but all necessary to faithfully
> > reproduce the tape later and/or to understand *why* the file might
> > (or can't) be used to completely reproduce the tape.
>
> Uh, again, can't understand why you'd need to recreate bad tapes.

Again...you're *NOT RECREATING BAD TAPES*.

> You might try hooking up with the emulator community and
> ask your questions there.

This being ClassicCmp, I thought they might be here, too :)

Besides, this isn't an emulator question so much as a data
preservation question.

Stan Sieler sieler_at_allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
Received on Thu May 02 2002 - 17:00:10 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:20 BST