> On 10/2/20 1:42 PM, Eric Smith via cctalk wrote:
>
> >/Of course, that scheme breaks programs that use tape images but don't
> >/>/expect enormous or "negative" record lengths. /
> Those would already be broken with Bob's use of large negative numbers for
> physical end of
> tape and 'bad block is here' (you don't get to know how big that bad block
> was, so that is
> hell with tapes with variable-length records, grumble..)
0xFFFFFFFF is end-of-medium. I've encountered only a few tapes with this
marker.
0xFFFFFFFE is an erase gap. I've never encountered one, perhaps because
I treat all 0xFFnnnnnn as EOM, even though they are reserved.
0x00000000 is a tapemark.
The above three are dataless.
0x80nnnnnn is a bad block (Medium Error) of size nnnnnn > 0. Woe to me
when my tape drive returns a zero-length block for those, so sometimes I
cobble up a BAD0 label and surround it with these Medium Errors.
Heroics can ask my tape drive what happened (to distinguish it from a
normal tapemark).
I could suggest that other values for the first byte might be used for
metadata, but I think there are too many readers and existing images to
let that work. I just put metadata in the same directory, but it can
get misplaced easily, and nothing limits a directory to just one tape
image. Not optimal.
>
> But for all the people who get clean reads off their tapes, none of this is
> an issue.
> I wish I was so lucky.
I can't believe that anyone never gets a clean read from any of their
tapes; most of mine have been clean. But not all of them...
--
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel. -Crow on solitaire
