Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!cs.utexas.edu!rice!sun-spots-request
From: c-art!jae@cs.utexas.edu (Yukon Born)
Newsgroups: comp.sys.sun
Subject: Re: Reading past EOT on Sun QIC tape drive
Keywords: Miscellaneous
Message-ID: <4350@brazos.Rice.edu>
Date: 15 Jan 90 16:03:59 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n5
X-Sun-Spots-Digest: Volume 9, Issue 11, message 2 of 15

In article <4235@brazos.Rice.edu> you write:
|X-Sun-Spots-Digest: Volume 9, Issue 5, message 13 of 19
|
|Can anyone tell me if it's possible to read past an end-of-tape mark on a
|Sun QIC tape drive (i.e., an "st" tape drive)?  One of my users
|accidentally blew away a tape he'd written by writing an empty file at the
|beginning of the tape.  Just about all of his data is still there, but I
|can't convince the st driver to let me read past the EOT marker.  It looks
|to me like the driver is trying to be too smart for its own good - is
|there a variable or something in the kernel I can patch to make the driver
|a little stupider...?  :-)

I tried to find this out because I did the same thing with a really
critical tape.  I got suggestions from the net, none of which helped.  I'm
no guru, but it seems to me the tape drive itself (the hardware) won't
proceed past an EOT - whatever I tried gave me a hard error.  If you
convince the software to ignore errors, the hardware forever tries to read
the EOT, or something.

If you find out how, _please let me know the trick_.  I even cut the tape
in the end - didn't work.  Here I think it's because the QIC format
doesn't get sync'ed up properly.