topix@gpu.utcs.utoronto.ca (R. Munroe) (04/09/91)
I am having trouble extracting some important data from a cartridge tape. I used tar and now can not retrieve the data. The tape drive whirrs and clicks a couple of times and then the system tells me to insert the next tape and press <CR> to continue. I know the data is on the tape - it justs seems that there is a little snag that makes the system think it's reached the end of the archive. Question - is there anyway way of retrieving the data (whatever is left of it) by either: 1. Some unix command that will read past the bogus 'end of archive'. or 2. Are there any companies that specialize in data recovery that could help. The tape is a 60MB Sony cartridge that was archived on a Silicon Graphics 4D/70 workstation (low density drive). I also have SGI 3130's and 4D/25's (Personal Irises) on site, that could be used if needed. Thanks for any and all help. Bob Munroe TOPIX Computer Graphics and Animation, Inc. Internet: topix@utcs.utoronto.ca AppleLink: CDA0695 CompuServe: 71160,3455 Voice: 416.971.7711
olson@anchor.esd.sgi.com (Dave Olson) (04/09/91)
In <1991Apr8.231456.391@gpu.utcs.utoronto.ca> topix@gpu.utcs.utoronto.ca (R. Munroe) writes: | I am having trouble extracting some important data from a cartridge tape. | I used tar and now can not retrieve the data. The tape drive whirrs and | clicks a couple of times and then the system tells me to insert the next | tape and press <CR> to continue. I know the data is on the tape - it justs | seems that there is a little snag that makes the system think it's | reached the end of the archive. Question - is there anyway way of retrieving | the data (whatever is left of it) by either: | | 1. Some unix command that will read past the bogus 'end of archive'. | | or | | 2. Are there any companies that specialize in data recovery that could help. | Unless you are getting kernel messages on the console or in SYSLOG, odds are VERY high that someone overwrote the beginning of the tape, perhaps by doing a 'tar c' with no args (fixed in the next release to be a no op, instead of trashing the tape), when they meant 'tar t'. If so, there is no hope. The firmware on the drives refuse to read past the EOD marker. Besides, it erased a part of each track when the the 'tar c', or whatever was done. This is one of thoese FAQ that shows up in all the comp groups from time to time. Remember, the write protect switch is your friend! If there were kernel messages of some kind, I might be able to help you decipher them. -- Dave Olson Life would be so much easier if we could just look at the source code.
scs@lokkur.dexter.mi.us (Steve Simmons) (04/10/91)
olson@anchor.esd.sgi.com (Dave Olson) writes: >In <1991Apr8.231456.391@gpu.utcs.utoronto.ca> topix@gpu.utcs.utoronto.ca (R. Munroe) writes: >| I am having trouble extracting some important data from a cartridge tape. >| I used tar and now can not retrieve the data. The tape drive whirrs and >| clicks a couple of times and then the system tells me to insert the next >| tape and press <CR> to continue. I know the data is on the tape - it justs >| seems that there is a little snag that makes the system think it's >| reached the end of the archive. Question - is there anyway way of retrieving >| the data (whatever is left of it) by either: >| >| 1. Some unix command that will read past the bogus 'end of archive'. >| >| or >| >| 2. Are there any companies that specialize in data recovery that could help. >| >Unless you are getting kernel messages on the console or in SYSLOG, odds >are VERY high that someone overwrote the beginning of the tape, perhaps >by doing a 'tar c' with no args (fixed in the next release to be a >no op, instead of trashing the tape), when they meant 'tar t'. >If so, there is no hope. The firmware on the drives refuse to read >past the EOD marker. Besides, it erased a part of each track when >the the 'tar c', or whatever was done. This is one of thoese FAQ >that shows up in all the comp groups from time to time. Remember, >the write protect switch is your friend! Hmmm...some help might be possible here. First, one needs to trick the drive into reading past the EOT (not EOD) marker. This *can* be done with some drives (I've done it), as long as one is careful. An EOT marker is two tape marks. So *if* the conjecture about a small tar blotzing the head of a large one is true, one could do so by doing mt -f <no_rewind_tape> fsf 1 ; mt -f <no_rewind_tape> fsf 1 Now the tape is positioned past the EOT mark. Use GNU tar to read the damaged data. -- "FACT: less than 10% of the psychiatrists in the US are actually practicing cannibals." Rod Johnson
dhinds@elaine19.Stanford.EDU (David Hinds) (04/10/91)
In article <1991Apr9.225311.6534@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >olson@anchor.esd.sgi.com (Dave Olson) writes: > >Hmmm...some help might be possible here. First, one needs to trick >the drive into reading past the EOT (not EOD) marker. This *can* be >done with some drives (I've done it), as long as one is careful. An >EOT marker is two tape marks. So *if* the conjecture about a small >tar blotzing the head of a large one is true, one could do so by doing > > mt -f <no_rewind_tape> fsf 1 ; mt -f <no_rewind_tape> fsf 1 > >Now the tape is positioned past the EOT mark. Use GNU tar to read the >damaged data. I didn't realize you could just step past the tape marks like this. What I've done before, to get past an EOD, is to rewrite another small archive over the one causing the problem, but then eject the tape from the drive before it writes its EOD. Then, reading the tape runs into a media error, but hopefully tar should try to resynchronize and read the rest of the tape. -David Hinds dhinds@cb-iris.stanford.edu
jeremy@perf2.asd.sgi.com (Jeremy Higdon) (04/10/91)
In article <1991Apr10.004953.17211@leland.Stanford.EDU>, dhinds@elaine19.Stanford.EDU (David Hinds) writes: > In article <1991Apr9.225311.6534@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: > >olson@anchor.esd.sgi.com (Dave Olson) writes: > > > >Hmmm...some help might be possible here. First, one needs to trick > >the drive into reading past the EOT (not EOD) marker. This *can* be > >done with some drives (I've done it), as long as one is careful. An > >EOT marker is two tape marks. So *if* the conjecture about a small > >tar blotzing the head of a large one is true, one could do so by doing > > > > mt -f <no_rewind_tape> fsf 1 ; mt -f <no_rewind_tape> fsf 1 > > > >Now the tape is positioned past the EOT mark. Use GNU tar to read the > >damaged data. > > I didn't realize you could just step past the tape marks like this. You can do this with a half-inch tape, or sometimes, with an Exabyte. The original poster had a cartridge tape, so I doubt that the above will work. > What I've done before, to get past an EOD, is to rewrite another small > archive over the one causing the problem, but then eject the tape from > the drive before it writes its EOD. Then, reading the tape runs into > a media error, but hopefully tar should try to resynchronize and read > the rest of the tape. > > -David Hinds > dhinds@cb-iris.stanford.edu
olson@anchor.esd.sgi.com (Dave Olson) (04/10/91)
In <1991Apr9.225311.6534@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: | olson@anchor.esd.sgi.com (Dave Olson) writes: | >Unless you are getting kernel messages on the console or in SYSLOG, odds | >are VERY high that someone overwrote the beginning of the tape, perhaps | >by doing a 'tar c' with no args (fixed in the next release to be a | >no op, instead of trashing the tape), when they meant 'tar t'. | | >If so, there is no hope. The firmware on the drives refuse to read | >past the EOD marker. Besides, it erased a part of each track when | >the the 'tar c', or whatever was done. This is one of thoese FAQ | >that shows up in all the comp groups from time to time. Remember, | >the write protect switch is your friend! | | Hmmm...some help might be possible here. First, one needs to trick | the drive into reading past the EOT (not EOD) marker. This *can* be | done with some drives (I've done it), as long as one is careful. An | EOT marker is two tape marks. So *if* the conjecture about a small | tar blotzing the head of a large one is true, one could do so by doing Bzzt. Sorry, you are wrong, An EOD marker on non-9track drives is NOT two filemarks. It is a specific set of information in the block headers that tells the drive that EOD has been reached. I haven't yet found a SCSI QIC drive that can be tricked into skipping past it. The '2 FMs means EOD' is just a convention on 9 track drives, and there is nothing special about 2 FM's in a row, as far as the drive is concerned. Many device drivers treat it specially, but that is a different issue altogether. -- Dave Olson Life would be so much easier if we could just look at the source code.