pax@ihu1e.UUCP (07/07/83)
Does anyone out there have a "fault tolerant" cpio ??? I have a cpio tape from 3 years ago written on an 11/70 with a couple of bad spots - can any of the files be recovered? Joe T. Hall IW iF-343 x.7650 ihu1e!pax
donn@sdchema.UUCP (07/08/83)
Does anyone out there have a "fault tolerant" cpio ???
I have a cpio tape from 3 years ago written on an 11/70
with a couple of bad spots - can any of the files be
recovered?
This can be done with the 4.1 BSD fault-tolerant 'tar' I sent out on
the net some time ago, believe it or not. The tape must have records
that are a multiple of 512 bytes in size and less than 10240 bytes
long, though -- I don't think this is a problem with cpio tapes. The
trick is to realize that the fault-tolerant tar has a 'junk' mode that
lets you collect data off the tape even if there is no valid 'tar'
checksum, and it ignores parity and other soft errors. This strategy
will fail only if by some miracle there is a valid 'tar' tape header
somewhere on the tape, in which case the 'tar' program will attempt to
'resynchronize'. A simple patch to the source code prevents this
behavior, however...
Some words of advice: I have found that parity errors on old tapes are
often due to little bits of cruft on the tape, and after a few passes
through the tape drive the bad spots sometimes magically disappear.
Sometimes.
Some systems have a 'dd' parameter called 'conv=noerror' which will
repeatedly try to read a bad block and skip it if this does not succeed
in making the error go away. This leads to 'gaps' in the output file
but sometimes this doesn't manage to damage anything useful. My
experience has been that a parity error hardly ever hurts very much
data, so the fault-tolerant 'tar' simply copies what it gets and tells
the user that it is suspicious. Since the tape DMAs directly into the
user's buffer on 4.1 BSD, plus there is a way of finding out what kind
of error occurred on the tape read, you can determine that there is a
usable buffer's worth of data even though the 'read' on the tape device
returned -1...
By the way, did anyone who tried the fault-tolerant 'tar' find problems
with occasionally truncated files? There was an off-by-one bug in it
that I fixed at some point in the past but I can't remember whether I
made the fix before or after posting... Oh well.
Donn Seeley UCSD Chemistry Dept. RRCF ucbvax!sdcsvax!sdchema!donn
(619) 452-4016 sdamos!donn@nprdctom@rlgvax.UUCP (07/08/83)
I don't have a fault-tolerant cpio handy, but here are some quick-and-dirty
alternatives:
1) Cpio needn't read a tape. If you have ANY utility to read in
a tape and skip over bad spots, use it to read the tape into a file.
It is important that SOMETHING be put in the file in place of the
bad blocks -- all nulls will do, but DON'T merely skip the bad blocks
and make the file shorter. Then try using cpio to read the file.
If you are lucky, the bad spots only occurred within one of the
archived files. That file will be corrupted, but the rest will
hopefully be extracted OK.
2) If that doesn't work, a little knowledge of cpio may help.
Each file in the archive is preceded by a header containing such little
tidbits as the name, size, permissions, etc. of the file. The very first
word of the header is the "magic number" 070707. So here's what you do:
Again, read in the file from tape somehow or another. This time its not
important that you supply something in place of the bad blocks; skipping
them will do. Then write a little program that reads the file and splits
it into separate files every time it sees the magic number. This gives
you your files, but you will have to manually go in and remove
the rest of the header information from the front of the file. Be careful,
its not likely to be ASCII.
So now your only problem is finding something that will read past a bad
spot on the tape. Hope your UNIX version allows it. Otherwise you'd better
look around for another system (UNIX or otherwise) that does.
- Tom Beres
{sesimo, allegra, brl-bmd, mcnc, we13}!rlgvax!tom