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. --Chuck > > (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 :) > > Stan > -- --Chuck ------------------------------------------------------------- "The first thing we do, let's kill all the spammers."
