cclist at sydex.com
Thu Aug 11 20:43:28 CDT 2016
On 08/11/2016 02:08 PM, Stan Sieler wrote:
> One important thing to do, depending upon your operating system and
> tape drive characteristics of course, is to issue read requests for a
> few bytes more than you expect ... because with some OSs and some
> kinds of drives, if you ask for X bytes and the record has more than
> X, you'll quietly get X and the rest will be discarded. (That came
> up in a court case where I was an expert witness ... an alleged
> 'expert' had copied a 9-track tape (badly) and lost data because the
> records were larger than he expected, and his copying tool didn't
> have that simple safeguard in it.)
If you're using a SCSI drive, that's pretty simple to read the tape in
"variable" block mode, leaving a generous buffer--the result sense
status will tell how much was read.
Pertec drives are super-stupid, so you start reading and counting bytes
until the block ends.
> A second thing is to be somewhat aggressive in reading the 'end' of
> the tape. The backup tapes I frequently encounter supposedly end with
> two EOFs in a row ... except for a few that happen to have extra data
> past that point :) (Of course, with 9 track tapes, you run the risk
> of going off the end!)
I've had a couple of tapes with "fooler" double file marks. The first
was a zero-length file--had I thought to look at the block count
(000000) in the HDR label, it would have been obvious.
The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine. However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel. Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape. What followed was a complete half-reel of
1600 data that would have been lost. My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended. I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.
War stories...I love 'em.
> (Yes, that begs the question...if you're archiving a tar tape ... do
> you *want* the data past the first EOF? (Which could be part of a
> prior (and longer) tar, or something else.)) (And then there are the
> people who put tar after tar after tar on the same tape :)
"The first thing we do, let's kill all the spammers."
More information about the cctech