Shortly after having posted my summary consisting of one answer, I
received the following extra messages. I haven't tried the scissors,
but everything else didn't work. The question I posted was regarding a
problem with a bad DAT tape which makes a restore abort in the middle
of it. Any attempt to access records past the bad spot on tape failed
because the drive immediately rewinds the tape. (Sorry, but I lost my
original posting...)
-Leonardo
------------------------------------
Date: Thu, 25 Jul 91 11:52:59 -0600
From: yih%atom@cs.utah.edu (Benny Yih)
You might try mechanically splicing out the length of tape up to the
bad spot, as a last try. Perhaps the drive will pick up the block after there.
luck, benny
------------------------------------
Date: Thu, 25 Jul 91 12:53:50 CDT
From: holle@asc.slb.com
try using cpio to read the tape. You've got nothing to lose now :-).
Also, try reading it remotely across the network.
-Kathy Holle Schlumberger
UNIX Systems Manager Austin Systems Center
ARPANET: holle@asc.slb.com 8311 North FM 620 Road
UUCP: uunet.uu.net!asc.slb.com!holle P. O. Box 200015
Austin, Texas 78720-0015
512-331-3000 (operator)
512-331-3646 (direct line)
------------------------------------
From: bb@math.ufl.edu
Date: Thu, 25 Jul 91 15:11:23 EDT
> Thanks, but the problem seems to be at much lower level: after some
> experimenting, I now think that the DAT tape drive senses the bad
> record and decides to abort everything and it even rewinds the tape. I
> double checked this theory by trying to skip over to the end of the
> dump file with "mt -f /dev/nrst1 fsf 1" but that fails too as soon as
> the bad record is encountered.
Sigh. That's the kind of problem you get when you put software in an
EPROM where you can't get to it. Raw device? What raw device??
Good luck.
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-------------------------------------------------------------------------------
Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb
University of Florida Internet: bb@math.ufl.edu
------------------------------------------
Date: Thu, 25 Jul 91 18:39:44 -0400
From: bzs@world.std.com (Barry Shein)
Have you tried just winding the tape forward by hand and inserting it,
and then doing something like a "dd" to suck off following blocks?
I don't know DAT, maybe it auto-rewinds when a new tape is put in, but
it's something I would try.
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
------------------------------------------
Date: Thu, 25 Jul 91 23:22:46 EDT
From: stern@sunne.east.sun.com (Hal Stern - Consultant)
you could have done major surgery: locate the spot on the tape
with the bad record, and then splice it out. you'll damage
the tar/dump archive, but you can work around that.
--hal
----------------------------------------
From: David Fetrow <fetrow@pike.biostat.washington.edu>
Date: Thu, 25 Jul 91 23:59:38 PDT
As a point of last resort, there are comanies that specialize in this.
Other things to try are different SCSI tape drives/drivers. Some recover
from errors better than others.
There's also scissors but I recommend against that.
------------------------------------------
Date: Fri, 26 Jul 91 19:37:41 EST
From: "Michael L. Squires" <sir-alan!mikes@iuvax.cs.indiana.edu>
Before giving up I would try with another drive, if one is available. This
is an old trick that has worked for me with diskettes and tapes in the past.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT