Tape dumping programs for Unix/Linux..

From: Raymond Moyers <rmoyers_at_nop.org>
Date: Thu May 2 20:15:37 2002

On Thursday 02 May 2002 18:52, you wrote:

> Someone had copied a tape whose records were 16 KB long using software
> that expected the records to be 8192 bytes longs ... and only asked
> for 8192 bytes in each read() request.

 Now i really do find this interesting

 Lets scope out some examples to illustrate my focus.

 On a floppy or a hard disk as examples you have
 pad data inbetween its records these are usually
 all FF's constant stream on 1's in other words
 then an address mark like FE followed by the header data
 Head Sector Cylinder ,, then some more FF's then a start
 of data mark the block of data then the CRC .. then all
 else is ignored ,, be it artifacts from a prev write ( hub speed jitter )
 or whatever .. the controller is looking for its string of a minimum
 number of 1's then the FE and so it repeats all round the disk.

 During lowlevel formatting you are basically building an image
 of this track .. complete with the between sector filler of FFs
 amd dumping a whole track at once with the write track command.

 These devices are random access, but when you pull the image
 off the device using it as a streamer, you are not getting
 the filler bytes the address marks or the crc's your getting
 only the content of the sectors (soft physical records)
 back to back a raw spool off a unix device with a typical
 device driver gives you the data without the controler
 interested bits off the media.

 I would assume that any decent unix driver up to the minimal
 expectations of behavior should act the same, including
 that for a proper interface to a 9 track tape.

 If the record length is varible, then is not the record length
 in the block headder ? and should not the driver read
 that from the headder then xxx bits of data ?

 it would seem that any tape used as a random access
 block device, that ever had a record re written would
 have garbage (from a prev update of that record)
 in the block,
 just like on a floppy where this happens all the time,
 (jitter again) and the controller simply ignores looking
 for its resetting minimal number of FF's and the next
 address mark

 ( im ignoring the hard sector media with a hole for
 every sector, but it would still apply in this scope
 albeit a bit differently)

 Now .. excuse me, but ive been around this stuff
 for a long time, and i think ive got a really firm grasp
 of the minimal amount of things needed in place for
 any data-to-media, data-from-media scheme to work.

 So, do i have this right ?

 That if i spooled off a 9 track tape, and assuming no
 non-recoverable media errors, that i would *not*
 get all of the data from all the records and without
 trailing garbage and the controler interested bits left out ?

 Knowing the proper expected behavior of any unix
 driver i could name ... i find this rather ....
 well unexpected.

 Raymond
Received on Thu May 02 2002 - 20:15:37 BST