12 Dec
2014
12 Dec
'14
8:54 a.m.
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.
And yes, I can read past double filemarks and get to the previously
written data. Eventually, a blank media or EOM condition arises and
calls a halt to things. Recently, I ran into a case where the
double-filemark was an accident--a zero-length file was written, so the
disrespect for double filemarks is necessary.
I've got an old X3T9 spec here, as well as a few vendors' manuals and
the strange non-filemark behavior isn't detailed--however, it's simple
enough to translate this into the expected "filemark-sensed" code.
It's not a stumble, just curiosity.
--Chuck