2 May
2002
2 May
'02
2:56 p.m.
On Thursday 02 May 2002 20:54, you wrote:
I just did a 'dd' of a bad QIC-80 tape; it
read the entire tape
as a single file, and didn't bail out.
I've not done that with magtape, but ISTR someone else here
saying that 'dd' does raw reads, bad blocks and all...
That may be the behavior of the qic driver, where err detection
(and just about everything else) is pushed up into userspace.
A Dat or a DC600 scsi will often bail out, sometimes the device
itself will stop (DAT) and your desire to have it keep marching
onward is thwarted.
if the tape and driver is well behaved you can usually use the mt
command to move down the tape to the next record and go
back to spooling off your files making a note to go back
and try the bad one again.
some of the poorly behaving DAT drives fall down so badly as to
need a reset or eject reload to get em talkling again.
You really have me going about the 9 track behavior tho
null portion of tape as record delimiters "crap in the gap"
problems of the past, and other such things.
So far what ive learned about those things is nothing as
many years around this stuff conditioned me to expect.
If i spool the whole raw tape using a driver that knows
nothing of any null gaps and simply spool all bytes that
are bytes to a file .... could not i then pull the desired content
out of the spool if i knew the format of the data ?
If random access is what they are doing, how did they deal
with a rewritten record, pad the unused portion of the record
to overwrite trailing garbage ? or was the bytecount in a rewritten
headder so that the controller knew the valid byte count ?
a tape with blank as delimiter/filler and records with no or
painfully terse descriptors seems to me very .... um something.