Tape dumping programs for Unix/Linux...

From: Raymond Moyers <rmoyers_at_nop.org>
Date: Thu May 2 21:56:13 2002

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.
Received on Thu May 02 2002 - 21:56:13 BST