10 Jun
2015
10 Jun
'15
11:19 a.m.
On 06/10/2015 11:12 AM, Mark J. Blair wrote:
No,
never OK. There is a format ID written OVER the BOT marker for 1600
and 6250 that tells the drive what the density format is. If you EVER
see the density change, is is because a tape was partially overwritten
at a different density, and then you've either read off the end of the
re-written portion, or the last EOF was lost somehow.
On Jun 10,
2015, at 08:46, Al Kossow <aek at bitsavers.org> wrote:
On 6/10/15 8:15 AM, Mark J. Blair wrote:
I particularly like the idea of
being able to extract questionable data and CRC/checksum.
Ok, now three more questions come to mind:
1) Is it ever acceptable to mix densities on a single tape? I'm not sure that my
Kennedy drive will even allow that, but I don't know if that is universal. And that is precisely why I'm thinking of an
ad-hoc interface rather than just plugging a SCSI drive into a UNIX box.
It also
has the advantage that you can return the CRC/checksum and partially read blocks. Most
SCSI tape drives don't
return the data if the read doesn't succeed. 2) What's the scoop on a final record overlapping
the EOT marker? Or even a new record starting after the EOT marker? I seem to recall
reading about some applications that stuck data after the EOT, such as backup volume
information.
Yeah, the EOT sensor is only an inch or so ahead of the write head, so
any long record will overlap the EOT sensor, and then the trailer and
EOF records will have to continue on past that for a few additional inches.
3) Did anybody ever go over to the dark side and
implement copy protection on magtapes, say, by deliberately including a record with bad
CRC that a normal driver+drive would not support writing? Or was that evil limited to the
floppy disk world?
UGH! You can't guarantee this would work on different vendor's hardware.
Jon