12 Dec
2014
12 Dec
'14
9:48 a.m.
On 12/12/14 8:54 AM, Chuck Guzis wrote:
On 12/12/2014 04:18 AM, Peter Corlett wrote:
This is bringing back a lot of bad memories..
You may want to look at
https://www.brouhaha.com/~eric/software/tapeutils/
and John Wilson's tapeio routines
I've run into problems with tapecopy where it gets stuck in an infinite loop writing
-1 byte
blocks if it ever runs into a bad block.
I'll have to look at the SCSI code I wrote back in 2001 for my direct SCSI tape reader
on MacOS
but I'm pretty sure I ended up having to read fixed-length 64k blocks there.
This gunk was creeping back up on my todo list as I really do need to retire my G3
powerbook that
I use for tape reading, mostly because I've been 'upgrading' my servers and
they no longer understand
AFP that OS9 uses.
My copy of the *draft* standard states "If
the logical unit encounters a
filemark during a READ command, CHECK CONDITION status shall be returned and
the filemark and valid bits shall be set to one in the sense data" but perhaps
the final standard decided to be different for perverse reasons. Draft copies
of questionable provenance is what everybody's working from though, because the
final versions are $$$.
Well, this is just odd--if I do my read not as variable length, but rather using
specified block size and the "fixed" bit (bit 0 of byte 1 in the READ command),
I do indeed get the filemark indication.
I'll have a look at the *nix tape driver code, but AFAIK, the standard tape handlers
for Linux and Unix depend on the block length being explicitly specified in a MODE SELECT
command. When doing
variable-length reads, this block length is 0.