• Please review our updated Terms and Rules here

QIC tapes: Skipping over files with errors - UNIX/CTIX & Linux

firebirdta84

Experienced Member
Joined
Jun 26, 2013
Messages
244
Location
Central Iowa
Progressing on now to reading some 25-30 year old QIC tapes (specifically DC600A, 9-tracks).

I'm able to read files right up until one experiences an error, but then I have trouble figuring out how to "jump over" that file, and try to read the next one (if that's even the right approach?)

I figured out how to tell the tape to move directly to the correct filemark, but it must still be doing error-checking along the way, because it gets hung up at the same place, and errors out, never reaching the filemark after the error.

I'm using
Code:
[FONT=Courier New]mt -f /dev/nst0 asf FileMarkNumber[/FONT]

I know that Al has done lots of readings of tapes of this vintage, and likely others here have as well, so I'm hoping to benefit from your experience on this.

Thanks again!
-AJ
 
It sounds like the linux tape device /dev/nst0 uses BSD semantics.

When a BSD-style tape device file is closed (i.e. dd exits after encountering a read error), the tape is left positioned at the end of the block that the read error occurred on. All that is required to continue reading the tape where the previous read left off (minus the block in error) is to open the tape device file again and start reading. It works the same way with positioning (mt fsf); mt ends when an error is encountered, causing the tape device to be closed. All you need to do is issue another 'mt fsf' to get to the next file mark (or keep doing it until you get a successful return code, in case of multiple errors). 'mt asf' may be more fragile in the event of encountering a tape error as I have seen some tape drive/tape driver combinations get confused/forget entirely about file position when encountering certain types of errors. You'll have to experiment.

This is NOT how a tape device with SysV semantics works. With SysV semantics, when the tape device is closed, the driver positions the tape to the beginning of the next file automatically (unless the tape is already on a filemark). So if the tape device gets closed after reading only part of a file (e.g. the program exits after encountering a read error), there is no way to get at any of the data between the error block and the end of the file.

Semantics don't matter if you have a program which doesn't close the tape device after encountering an error. The 'copytape' program may work this way; I'd have to check the source again. But dd and mt (as well as pretty much any other normal unix program for handling tapes) are both designed to exit on error, which causes the tape device file to be closed, and the driver semantics to matter.
 
Thanks for this, as well as your email, Bear. Much appreciated! I welcome more of your insight here, and I will continue to experiment and report back here.

-AJ
 
Back
Top