[NCLUG] fixing corrupt cpio archive

[Aaron D. Johnson]

> To be sure, the example could lead one to that conclusion, but
> in fact the same thing occurs if I do
> 	$ zcat foo.cpio.Z | cpio ...
> or
> 	$ gunzip foo.cpio.Z
> 	$ cat foo.cpio | cpio ...
> 
> In that case it's the filesystem that stops feeding bytes to the
> file handle bash associates with the pipe to cpio.

OK.  In the second case, foo.cpio only contains the bits that gunzip
was able to recover from the corrupted foo.cpio.Z.  You're really in
no different a situation than when feeding zcat's output straight to
cpio.

The unexpected EOF message comes up because cpio doesn't think the
archive should have ended at the point which read(2) failed or
returned short.  It stopped in the middle of an archive member, for
instance.

> > But you're basicly SOL.  :( FWIW, you'd probably be just as bad
> > off had you used gzip and tar.
> 
> Am I just weird or is it reasonable to expect an archive format to
> include sufficient redundancy to support a certain level of
> bit-error recovery? Is there a popular archive format that does?
> (These days I mainly use zip, because it's cross platform: Windows,
> all forms of UN*X, and the Java standard library. Also, I detest
> tar's command-line semantics. (I hear great things about the
> simple-to-decode byte layout however.))

Well, compress' job is redundancy removal.  tar and cpio will both
deal with corrupted archives to some extent, but they can only use the
bits they are given.

Zip compresses each archive member individually.  So if one bit gets
flipped in the middle of the compressed data it can skip ahead to the
next archive member and go to work on that one.  You can do the
equivalent with tar or cpio by running compress or gzip or bzip or
whatever on each file you'll be archiving and then creating an archive
of compressed files.  You'll probably lose some compression ratio
versus compressing an archive of uncompressed files, though.  Your
choice.

If you want to be able to recover data from faulty media, something
like http://freshmeat.net/projects/vdmfec/ will be your best bet, but
you'll need to write it out using that tool to begin with.  IIRC,
FastBack for DOS did something vaguely like this.

- Aaron