On 2014-12-12 17:54, 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.
I don't know much of anything about the low level SCSI details here. So
I can't comment on that.
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.
Two tape marks is just a convention used by some software to indicate
the logical EOT. It has no special meaning for the hardware. In fact,
standard ANSI formatted tapes can legally contain two consecutive tape
marks without it being the EOT. ANSI instead have a special record to
indicate EOT.
Johnny