pjc@cc.ic.ac.uk (01/25/91)
From: pjc@cc.ic.ac.uk () Newsgroups: comp.unix.ultrix Subject: Tape problems References: Sender: Followup-To: Distribution: world Organization: Imperial College Computer Centre Keywords: Problem: TK50 that has had the front of a tar file overwritten by another much shorter one. Can I get at any of the data of the original file on the tape? I am willing to consider manually winding on the TK50 If I have to. MT seems unable to get past the EOF and the first partial block on the tape. Any ideas or should I give up? Thanks.
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/25/91)
In article <1991Jan24.213649.2804@cc.ic.ac.uk> pjc@cc.ic.ac.uk writes: > TK50 that has had the front of a tar file overwritten by another > much shorter one. Can I get at any of the data of the original file > on the tape? > I am willing to consider manually winding on the TK50 If I have to. > MT seems unable to get past the EOF and the first partial block on > the tape. The default device used by the mt command is likely to rewind after obeying your instructions, so you might not know if it has gotten past the EOF. Try: % mt -f /dev/nrmt0h fsf 1 % mt -f /dev/nrmt0h fsr 1 % dd if=/dev/nrmt0h of=whatever bs=10240 However, the EOF might actually be two EOFs (convention for the end of the last file). So, if the above fails, then % mt -f /dev/nrmt0h rew % mt -f /dev/nrmt0h fsf 2 % mt -f /dev/nrmt0h fsr 1 % dd if=/dev/nrmt0h of=whatever bs=10240 Substitute /dev/nrmt0l or other device name if necessary. These are not the company's suggestions. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila) (01/27/91)
pjc@cc.ic.ac.uk writes: >From: pjc@cc.ic.ac.uk () >Newsgroups: comp.unix.ultrix >Subject: Tape problems >References: >Sender: >Followup-To: >Distribution: world >Organization: Imperial College Computer Centre >Keywords: >Problem: > TK50 that has had the front of a tar file overwritten by another > much shorter one. Can I get at any of the data of the original file > on the tape? > I am willing to consider manually winding on the TK50 If I have to. > MT seems unable to get past the EOF and the first partial block on > the tape. > Any ideas or should I give up? > Thanks. Je.. je.. I has the same problem some weeks ago (on a TU81 tape), and after some delivering and studing :-) I recover my tape :-) : First mount your tape, then do a: mt -f /dev/rmt? eotdis ; with this you disables de EOT Then do : mt -f /dev/nrmt? fsr 55 **NOTE: Use the nrmt? for NOT-rewind tape, fsr is forward records, and CHECK that 55 works for you.. it works for mebut in a TU81 ok? BYE. Jose A. Vela Avila josevela@mtecv2.mty.itesm.mx
terry@geovision.uucp (Terry McGonigal) (01/28/91)
In <1991Jan25.045736.12356@tkou02.enet.dec.com> diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: > In article <1991Jan24.213649.2804@cc.ic.ac.uk> pjc@cc.ic.ac.uk writes: > > > TK50 that has had the front of a tar file overwritten by another > > much shorter one. Can I get at any of the data of the original file > > on the tape? > > I am willing to consider manually winding on the TK50 If I have to. > > MT seems unable to get past the EOF and the first partial block on > > the tape. > > The default device used by the mt command is likely to rewind after > obeying your instructions, so you might not know if it has gotten past > the EOF. Try: > [ suggestions omitted ] My experiences with this problem would suggest that it's not software EOF marks that are the trouble here, but rather a hardware EOT mark that the TKxx driver writes to the tape when it's finished writing to it. Some poking around in man pages and .h's lead me to beleive that there is a command you can give the drive to both write and erase these marks, but I could'nt fingure out how to get the commands through the ioctl interface. It does not, however seem to be possible to get the drive to space past or over one of these marks, the drive `thinks' the tape ends there and gives only i/o errors (I think, it's been a while) if you try to move past it. We eventualy hit upon the idea of powering off the system (a GPX/II) during a tar, which did work, leaving us with a tape w/o the EOT mark that gets written when tar finishes (normally :), but this hardly seems like a sane solution. As it is a potentially common problem, I too would be interested in any less drastic solutions... > > These are not the company's suggestions. > -- > Norman Diamond diamond@tkov50.enet.dec.com > If this were the company's opinion, I wouldn't be allowed to post it. > Cheers, -- Terry McGonigal GeoVision Corp {uunet,cunews!cognos}!geovision!terry Ottawa On, Can tmcgonigal@gvc.com 613-722-9518
mike@raven.uss.tek.com (Mike Ewan) (01/31/91)
In article <1355@geovision.UUCP>, terry@geovision.uucp (Terry McGonigal) writes: |> In <1991Jan25.045736.12356@tkou02.enet.dec.com> |> diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: |> |> > In article <1991Jan24.213649.2804@cc.ic.ac.uk> pjc@cc.ic.ac.uk writes: |> > |> > > TK50 that has had the front of a tar file overwritten by another |> > > much shorter one. Can I get at any of the data of the original file |> > > on the tape? |> > > I am willing to consider manually winding on the TK50 If I have to. |> > > MT seems unable to get past the EOF and the first partial block on |> > > the tape. |> > |> > The default device used by the mt command is likely to rewind after |> > obeying your instructions, so you might not know if it has gotten past |> > the EOF. Try: |> > |> [ suggestions omitted ] |> |> My experiences with this problem would suggest that it's not software |> EOF marks that are the trouble here, but rather a hardware EOT mark that |> the TKxx driver writes to the tape when it's finished writing to it. |> |> Some poking around in man pages and .h's lead me to beleive that there is |> a command you can give the drive to both write and erase these marks, but |> I could'nt fingure out how to get the commands through the ioctl interface. |> It does not, however seem to be possible to get the drive to space past |> or over one of these marks, the drive `thinks' the tape ends there and gives |> only i/o errors (I think, it's been a while) if you try to move past it. |> [stuff deleted] The TK driver sets an error condition on EOF that must be cleared before you can read the next file. Simply closing the device and opening it again will clear the error. If it's an EOT problem then: "mt -f /dev/rmt0h eotdis; mt -f /dev/nrmt0h fsf 2" may work to get past the EOT mark. Mike -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!uunet!raven.uss.tek.com!mike Tektronix, Inc. Compuserve: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart