Tape dumping programs for Unix/Linux..
Re:
> > > Unix will treat any device as a stream of bytes
> >
> > And therein lies the problem.
>
> You would rather work the drive to death ?
> You know, any really old tape you are attempting to recover
> you really do not want to be running it thru the tape deck
> very much
>
> disks are huge these days, and the content is best messaged
> on a new disk rather than an old tape.
Absolutely! Very good point.
However, if I notice recovered-reads (or hard errors) on old 9-track
tapes, I often see fewer recovered reads (or hard errors) if I try
the tape one more time. I assume that going over the heads once
may have knocked off a bit of dust/dirt/something that affected
the tape the first time. Note that I don't discard the
results of the first run until the second run finishes...
I've had one tape break during a second run :)
> > Go buy a 9-track drive and hang it on your *nix box.
> > Let me send you a 9-track tape. You read it any way
> > you want. You send me the tape back.
>
> > Then you go get a second tape, and put the data back on
> > any way you want. Then send it to me, and I'll tell you
> > if your technique works or not.
BTW, the only way you can be *SURE* you got all the data on
the tape is if *EVERY* read-request returned fewer characters
than you asked for. E.g., if you did:
bytesread = read(fromfd, buffer, BUFSIZE);
and you get BUFSIZE bytes in, then there's a chance that that
tape record had BUFSIZE + 100 bytes ... and you've just lost
those last 100 bytes.
Sure, sure ... it's not a major problem if you know the tape
format ahead of time. (E.g., MPE V tapes can't have records
more than 64 KB, and the actual limit is somewhat less than that.)
But the point applies to unknown tapes.
Stan Sieler sieler_at_allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
Received on Thu May 02 2002 - 17:06:55 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:35:20 BST