SCSI tape question

[Al Kossow]

On 12/12/14 8:54 AM, Chuck Guzis wrote:
> On 12/12/2014 04:18 AM, Peter Corlett wrote:
>
>> 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.
>

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.