herb@blender.UUCP (Herb Peyerl) (12/15/89)
Last night we spent quite a number of hours trying to salvage a tape that someone had destroyed by writing volume 2 over top of volume 1. (ie: when it asked for the second tape, receptionist hit return). The file section we wanted to get back was the portion after the overlap. This was on a PC/RT using a 6157-002...The problem was that AIX absolutely refused to go past the end-of-file markers written on the middle of the tape... In the manual it says several things of which we tried all in various transformations and contortions and none of them worked properly... ie: use fskip in dd to skip past 'x' end-of-file markers. The only value that had any sort of affect was fskip=0 which of course produced the first file section. fskip=-1 for some reason had the same affect, but this was when we started getting desperate... using any value higher than 0 either left the tape drive in a state where it required a "tctl reset" or produced nothing. We were using /dev/rmt4 to keep the tape positioned generally where we wanted it... ie: tctl fsf 1 or fsr x to reposition the tape and start reading. This seemed to reposition the tape but then reading produced an error. Using dd with the 'noerror' option kept it going in an infinite loop trying to read the same record over and over again. We finally managed to get back about 1 record by simulating the circumstances (ie: Write one meg of data to the tape, then overwrite the beginning with a smaller file). What we did when writing the smaller file section was not to let it finish, just open the tape drive. From there we were able to use dd to read in some data... Since there wasn't an end-of-file marker written, the tape drive didn't have a fit, however, it would only allow us to read one record and then bombed out... My main question is, has anyone else done this??? I'm rather perplexed about why these methods didn't work... The only thing we could think of was that the RT Tape device driver was too smart for it's own good and wouldn't let the tape go past any sort of error condition. Or perhaps it's the physical hardware doing this... -- --------------------------------------------------------------------- UUCP: herb@blender.UUCP || ...calgary!xenlink!blender!{herb||root} ICBM: 51 03 N / 114 05 W || Apollo Sys_admin, Novatel Communications "The other day, I...... No wait..... That wasn't me!" <Steven Wright>