dd fskip=1

[Herb Peyerl]

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 at 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>