2 Oct
2020
2 Oct
'20
6:29 p.m.
On 10/2/20 1:42 PM, Eric Smith via cctalk wrote:
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.
/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..)
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