olson@newmedia.esd.sgi.com (Dave Olson) (01/17/91)
In <1991Jan16.001634.9049@news.arc.nasa.gov> mwilson@max.arc.nasa.gov (Michael A. Wilson) writes: | | I have a bit of a problem concerning 1/4" tapes written with tar: | | I have a tape that has been overwritten. The user had created a tar | archive tape previously. He created a new directory | and then typed "tar cv" instead of "tar xv", so he has destroyed at | least the first 400 blocks of the archive. Is there any way to extract | the rest of the archive? | | I have tried to get past this first tar block by using dd. The problem | is that I get an end of media after 400 blocks, and I don't seem to | be able to get beyond it using dd. | | any and all help would be appreciated. I am using an SGI 4D240S with | IRIX 3.3. Sorry, but the QIC drive specs allow no way to get past the EOD. You are out of luck (it isn't an issue with the tape driver, but rather with the drive firmware and hardware).
olson@anchor.esd.sgi.com (Dave Olson) (01/19/91)
In <1991Jan17.195800.14456@portia.Stanford.EDU> dhinds@elaine15.stanford.edu (David Hinds) writes: | In article <1991Jan17.003628.17045@odin.corp.sgi.com> olson@newmedia.esd.sgi.com (Dave Olson) writes: | >| I have a tape that has been overwritten. The user had created a tar | >| archive tape previously. He created a new directory | >| and then typed "tar cv" instead of "tar xv", so he has destroyed at | >| least the first 400 blocks of the archive. Is there any way to extract | >| the rest of the archive? | >| | >Sorry, but the QIC drive specs allow no way to get past the EOD. You | >are out of luck (it isn't an issue with the tape driver, but rather | >with the drive firmware and hardware). | | Well, there is a way to get past the EOD, but I'm not sure how much good it | will do you. I did this recently when I accidentally overwrote the header | of a 'bru' archive. I just overwrote the EOD I wanted to get past with a | short archive, but ejected the tape before the archive finished. This is the key. If you ejected the tape, the tape drive never created the EOD indication. Therefore it simply looks like a bad data block (or possibly a media error, depending on how rough you were :) ). | When I then re-read the tape, 'bru' read my new archive header and the truncated | part of that archive, then registered a hard tape error, and re-synchronized | with the original archive I was trying to recover. I recovered the rest of | the tape without any problems. The reason I don't think this will help you | is that 'tar' can't recover from this kind of error in a tape. Sure it will. The 'e' option of tar is intended for exactly this kind of problem ('corrupted' data on the tape. However, it won't help for the more common case of the original posting, since in that case the drive did write the EOD indicator. -- Dave Olson Life would be so much easier if we could just look at the source code.
dhinds@elaine20.stanford.edu (David Hinds) (01/19/91)
In article <1991Jan18.185120.22578@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: >In <1991Jan17.195800.14456@portia.Stanford.EDU> dhinds@elaine15.stanford.edu (David Hinds) writes: >| Well, there is a way to get past the EOD, but I'm not sure how much good it >| will do you. I did this recently when I accidentally overwrote the header >| of a 'bru' archive. I just overwrote the EOD I wanted to get past with a >| short archive, but ejected the tape before the archive finished. > >This is the key. If you ejected the tape, the tape drive never created >the EOD indication. Therefore it simply looks like a bad data block >(or possibly a media error, depending on how rough you were :) ). > >| When I then re-read the tape, 'bru' read my new archive header and the >| truncated part of that archive, then registered a hard tape error, and >| re-synchronized with the original archive I was trying to recover. I >| recovered the rest of the tape without any problems. The reason I don't >| think this will help you is that 'tar' can't recover from this kind of >| error in a tape. > >Sure it will. The 'e' option of tar is intended for exactly this kind >of problem ('corrupted' data on the tape. However, it won't help for >the more common case of the original posting, since in that case the >drive did write the EOD indicator. Well, yes, but the original poster can easily create my situation the same way I did, by overwriting his initial mistake but ejecting the tape before it writes an EOD. It will just cost him a little bit more of his data, depending on how quick he is with the drive door. It might work, but when I tried taking two tar files, spliced them together in the middle at some random point, and tried reading the spliced file with tar -e, I couldn't get tar to recover any files past the error. It did detect an error in the file, and tried to keep reading, but couldn't resynchronize with the second tar file. Maybe it would do better if it hit a hard error on a tape. It is worth a try, in any case, unless anyone can think of a way to read the tape without losing any more data. -David Hinds dhinds@cb-iris.stanford.edu