news@bjm.wimsey.bc.ca (News Login) (12/12/90)
Hi NET, I have this backup which I accidentally wrote a cpio archive over. However the cpio archive is only 20 megabytes and therefore 1/3 of the tape. What I really want to do is get past the cpio archive and just retreive the rest of the tape into a file and I will fix the remaining tar file by hand. My question is (drum roll please) how do get past the EOF marker at the end of the cpio? I've tried dd, cat, evmt (a utility which comes with ESIX [which I'm now running] which is similar to sco xenix's 'tape' utility) which allows me to get to the next eof but not past it. I don't really care how much past the eof I go (.5 to even 1 meg if I have to). I think what I mostly overwrote was the /bin /usr/bin stuff. Any ideas would be much appreciated.
kittlitz@mips2.cr.bull.com (Ned Kittlitz) (12/12/90)
In article <1990Dec12.050414.15575@bjm.wimsey.bc.ca> news@bjm.wimsey.bc.ca (News Login) writes: >Hi NET, > > I have this backup which I accidentally wrote a cpio archive over. >However, the cpio archive is only 20 megabytes and therefore 1/3 of the tape. You don't say so explicitly, but by the process of multiplication, I am going to assume that you are talking about a 60MB 1/4 inch cartridge tape. If so, several ravens which I have at hand quoth "nevermore". From the Archive Viper description of write: "QIC data can only be written over erased tape; therefor, when the Viper drive writes to track zero, the erase head is turned on to condition the entire tape". From the Wangtek OEM manual for 5099ES/5125ES/5150ES streaming 1/4 inch tape cartridge drive: "Tape is erased automatically while writing track zero." ---------- E. N. Kittlitz - consulting at Bull, and nothing more. kittlitz@world.std.com or kittlitz@granite.cr.bull.com
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (12/14/90)
In article <1990Dec12.050414.15575@bjm.wimsey.bc.ca> news@bjm.wimsey.bc.ca (News Login) writes: > I have this backup which I accidentally wrote a cpio archive over. >However, the cpio archive is only 20 megabytes and therefore 1/3 of the tape. I think what you are asking here is 'How do I read beyond the end of the EOF mark on the tape'. The problem is that, when whichever process you use to read past the first file closes the device, it automatically rewinds. There should be a different device (same major, different minor number) that is explicitly no-rewind-on-close. On my PRIME EXL (386 MultiBusII/SCSI, ATT Unix Sys V 3.1.2), I have: $ l /dev/rct total 0 crw-rw-rw- 2 root sys 1,160 Dec 13 12:19 c0d5 crw-rw-rw- 1 root sys 1,164 Jun 27 10:56 c0d5n crw-rw-rw- 1 root sys 1,165 Feb 18 1989 c0d5w $ Controller 0 (SCSI) device 5 (cartridge tape) no-rewind is the second device here. Once you've that device, use cpio or dd to read to the end of it, then reopen the either the regular or the no-rewind device with dd to suck in the data beyond the EOF mark. Don't forget to rewind the tape after the last read, before you pull it from the drive! Good luck Dan
randyj@bcs800.UUCP (Randy Jarrett) (12/15/90)
In <1990Dec12.050414.15575@bjm.wimsey.bc.ca> news@bjm.wimsey.bc.ca (News Login) writes: >Hi NET, > > I have this backup which I accidentally wrote a cpio archive over. However >the cpio archive is only 20 megabytes and therefore 1/3 of the tape. What I >really want to do is get past the cpio archive and just retreive the rest of >the tape into a file and I will fix the remaining tar file by hand. My >question is (drum roll please) >how do get past the EOF marker at the end of the cpio? I've tried dd, cat, >evmt (a utility which comes with ESIX [which I'm now running] which is similar >to sco xenix's 'tape' utility) which allows me to get to the next eof but >not past >it. I don't really care how much past the eof I go (.5 to even 1 meg if I have >to). I think what I mostly overwrote was the /bin /usr/bin stuff. I have had a similar experence in the recent past. What I was able to do was to read the first portion (your cpio) with the -ivtc option and using the no-rewind device which will leave the tape sitting at the end of the cpio section. You can then continue on however you want to get the rest of the tape. In my case I used cpio with the 'k' option to skip bad sections and start at the next valid header. I don't know that tar has any such options.. Good luck Randy Jarrett WA4MEI | US SNAIL: 2859 Paces Ferry Rd. UUCP ...!emory!bcs800!rsj | Suite 1000 PHONE +1 404 431 1200 | Atlanta, GA 30339
rbj@uunet.UU.NET (Root Boy Jim) (12/19/90)
>>I have this backup which I accidentally wrote a cpio archive over. However >>the cpio archive is only 20 megabytes and therefore 1/3 of the tape. What I >>really want to do is get past the cpio archive and just retreive the rest of >>the tape into a file and I will fix the remaining tar file by hand. My >>question is (drum roll please) >>how do get past the EOF marker at the end of the cpio? System V-oids have no "mt" program. They think they don't need one. In a minimal sense, they are correct. mt -f /dev/nrmt0 rew -> echo Rewinding < /dev/rmt0 mt -f /dev/nrmt0 fsf -> echo Skipping < /dev/nrmt0 You take the low road and I'll take the high road. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
tneff@bfmny0.BFM.COM (Tom Neff) (12/20/90)
In article <114820@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >System V-oids have no "mt" program. Better start eating more root vegetables, Root Boy. System V/386 has 'tapecntl' which does the same thing. tapecntl -r tapecntl -p tapecntl -e etc. Note: for some strange reason not every reseller bundles 'tapecntl' but it is portable across versions modulo the choice of node names.
tim@delluk.uucp (Tim Wright) (12/21/90)
In <94408978@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >In article <114820@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >>System V-oids have no "mt" program. Not true of all of them. Interactive supply it. It doesn't work as supplied in vanilla V.4 'cos it's got all the BSD tape ioctls which don't behave very well with the System V style tape driver :-(. Somebody fixed that up in Austin. Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
mike@bria.AIX (Mike Stefanik/78125) (01/02/91)
>In <1990Dec12.050414.15575@bjm.wimsey.bc.ca> news@bjm.wimsey.bc.ca (News Login) writes: > >I have this backup which I accidentally wrote a cpio archive over. However >the cpio archive is only 20 megabytes and therefore 1/3 of the tape. What I >really want to do is get past the cpio archive and just retreive the rest of >the tape into a file and I will fix the remaining tar file by hand. My >question is (drum roll please) >how do get past the EOF marker at the end of the cpio? I've tried dd, cat, >evmt (a utility which comes with ESIX [which I'm now running] which is similar >to sco xenix's 'tape' utility) which allows me to get to the next eof but >not past >it. I don't really care how much past the eof I go (.5 to even 1 meg if I have >to). I think what I mostly overwrote was the /bin /usr/bin stuff. First you have to skip over the first "part" of the tape that you cpio'd to; use the no-rewind tape device (ours is rmt4) and do: $ dd if=/dev/rmt4 of=/dev/null bs=512k Then use dd to pull in the last "part" of the tape which is your tar'd files: $ dd if=/dev/rmt4 of=/tmp/damaged bs=512k You can then pick through /tmp/damaged which would contain what remains of your tar'd files. ----------------------------------------------------------------------------- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike "If it was hard to code, it should be harder to use!"
martin@mwtech.UUCP (Martin Weitzel) (01/03/91)
In article <301@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: :>In <1990Dec12.050414.15575@bjm.wimsey.bc.ca> news@bjm.wimsey.bc.ca (News Login) writes: :> :>I have this backup which I accidentally wrote a cpio archive over. However :>the cpio archive is only 20 megabytes and therefore 1/3 of the tape [...] :>My question is (drum roll please) :>how do get past the EOF marker at the end of the cpio? [...] :First you have to skip over the first "part" of the tape that you cpio'd to; :use the no-rewind tape device (ours is rmt4) and do: : : $ dd if=/dev/rmt4 of=/dev/null bs=512k : :Then use dd to pull in the last "part" of the tape which is your tar'd files: : : $ dd if=/dev/rmt4 of=/tmp/damaged bs=512k : I know this was allready mentioned earlier in this thread, but I think I should repeat for all those who tuned in late: ALL THIS IS TECHNICALLY CORRECT BUT BOUND TO FAIL FOR TYPICAL CARTRIDGE TAPE STREAMERS, SINCE THESE DEVICES PHYSICALLY ERASE ALL OF THE TAPE WHEN WRITING THE FIRST TRACK! (IMHO the topic should go into the FAQ.) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (01/03/91)
In article <1023@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: %In article <301@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: %:First you have to skip over the first "part" of the tape that you cpio'd to; %:use the no-rewind tape device (ours is rmt4) and do: %: %: $ dd if=/dev/rmt4 of=/dev/null bs=512k %: %:Then use dd to pull in the last "part" of the tape which is your tar'd files: %: %: $ dd if=/dev/rmt4 of=/tmp/damaged bs=512k %... %ALL THIS IS TECHNICALLY CORRECT BUT BOUND TO FAIL FOR TYPICAL CARTRIDGE %TAPE STREAMERS, SINCE THESE DEVICES PHYSICALLY ERASE ALL OF THE TAPE %WHEN WRITING THE FIRST TRACK! % %(IMHO the topic should go into the FAQ.) %-- %Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83 I'm not sure I follow this...How can a drive "Physically Erase" a portion of tape that has not passed under the head? I've actually performed the above operation on a QIC-24 cartridge. Dan ---
kittlitz@granite.cr.bull.com (Edward N. Kittlitz) (01/04/91)
Cartridge tapes are recorded in "serpentine" format. I believe a 150MB tape has 18 tracks. You can think of it as 1->1->1->.....1-> 2<-2<-2<-....<-<2 3->3->3->.....3-> etc. (although it isn't actually in that order). I am no peripherals expert, but it seems to me that there are several advantages: - as recording heads (tracks) get thinner, you get more on the same length of tape. Of course you probably need to make the tape with a better magnetic coating, but you aren't doing the audio cassette trick of thinner tape (am I correct here?) to get more info into the same physical cartridge container. - it should be easier to keep the tape streaming, because a track is only 1 bit wide. From my reading of the Wangtek 5150 and Archive 2150 manuals, the erase head is full width. I don't know if there are actually 18 "tips" on a fixed head for recording/sensing, or whether the record/sense head moves up and down. I have a suspicion it is the latter, as I have watched an internal cart-tape drive move a head assembly across the width of the tape during tape load. ----- E. N. Kittlitz kittlitz@granite.cr.bull.com Contracting at Bull, but not alleging any representation of their philosophy.
fnf@fishpond.uucp (Fred Fish) (01/21/91)
In article <1023@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >I know this was allready mentioned earlier in this thread, but I think >I should repeat for all those who tuned in late: > >ALL THIS IS TECHNICALLY CORRECT BUT BOUND TO FAIL FOR TYPICAL CARTRIDGE >TAPE STREAMERS, SINCE THESE DEVICES PHYSICALLY ERASE ALL OF THE TAPE >WHEN WRITING THE FIRST TRACK! Add to this that it is also bound to fail for any typical 1/4" cartridge which is written and later develops a "bad spot". I know of no stock drives for which any portion of the tape after the bad spot will be readable. Apparently the firmware refuses to have anything to do with any portion of the tape after the bad spot. >(IMHO the topic should go into the FAQ.) Amen. This comes up at least once or twice a month. -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!mcdphx!fishpond!fnf
david@talgras.UUCP (David Hoopes) (01/21/91)
In article <1991Jan20.172639.364@fishpond.uucp> fnf@fishpond.uucp (Fred Fish) writes: >In article <1023@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >>I know this was allready mentioned earlier in this thread, but I think >>I should repeat for all those who tuned in late: >> >>ALL THIS IS TECHNICALLY CORRECT BUT BOUND TO FAIL FOR TYPICAL CARTRIDGE >>TAPE STREAMERS, SINCE THESE DEVICES PHYSICALLY ERASE ALL OF THE TAPE >>WHEN WRITING THE FIRST TRACK! > True. I have done this myself. Once you start writing its gone. Now anytime I want to restore from a tape I turn the little write protect notch to point at safe. I reccomend this on any kind of a tape drive. Chances are that by the time you go to restore something off a tape you are worried about getting your data back. This is the time that human error is most likely to happen. USE THE WRITE PROTECT!!!! >Add to this that it is also bound to fail for any typical 1/4" cartridge >which is written and later develops a "bad spot". I know of no stock >drives for which any portion of the tape after the bad spot will be >readable. Apparently the firmware refuses to have anything to do with >any portion of the tape after the bad spot. > This is not true. The hardware and firmware are capable of reading past bad spots. I also know that Tallgrass drivers will read past a bad spot. I have tested this myself by creating bad spots both physically (punching a hole in the tape) and with a magnet. Of course the data at the bad spot is lost but data past the bad spot can be recovered. Note that application software must have the ability to handle this. Tar and some versions of cpio do not. The cpio that is created by PAX does and our FileSecure IX software ( A Tallgrass Technologies product) does. >>(IMHO the topic should go into the FAQ.) > >Amen. This comes up at least once or twice a month. > I second the motion. >-Fred >-- ># Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA ># 1-602-491-0048 asuvax!mcdphx!fishpond!fnf -- --------------------------------------------------------------------- David Hoopes Tallgras Technologies Inc. uunet!talgras!david 11100 W 82nd St. Voice: (913) 492-6002 x323 Lenexa, Ks 66214