[NCLUG] fixing corrupt cpio archive

Aaron D. Johnson adj at ccltd.com
Mon Nov 19 10:40:17 MST 2001


> Any uncompress/gunzip gurus out there?  How about cpio experts?
> 
> Back in the day, I had some files I wanted to keep around forever so
> I stored them as compress'ed cpio archives. (Dumb twice, but there
> it is.)

Eh?  Nothing wrong with cpio.  Except maybe that there are umpteen
different versions.  (A somewhat lesser issue with tar.)  At least you
can get it to store a checksum of archive members in the archive.  And
you can do that cool pipe-a-big-list-of-files-to-cpio's-standard-input
thing to tell it what to archive.  (Yeah, GNU tar can do that, too.)

> Nobody has uncompress anymore (thanks a lot, Unisys) but gunzip

Decompressing isn't covered by the patent, thankfully.

> has the equivalent capability. Some of the .cpio.Z files give me
> 
> $ gunzip foo.cpio.Z 
> gunzip: foo.cpio.Z: corrupt input. Use zcat to recover some data.
> 
> and the man page is pretty unhelpful. (It says zcat will read up to
> the point of failure, but no hints as to how to skip the bad part
> and continue on after. Perhaps that's not possible with .Z files,
> but I'm hoping it is.)

It doesn't look like it's possible.  :(

> Not all the .cpio.Z files got corrupted that way. Some have a
> different type of problem:
> 
> $ file bar.cpio 
> bar.cpio: ASCII cpio archive (pre-SVR4 or odc)
> 
> and when I do (excuse the useless use of cat)
> 
> $ zcat bar.cpio.Z | cpio -i -t -d -H odc
> -rw-r-Sr--   1 719      124          1166 Mar  3  1989 graphics.two/clipper.c
> -rw-r-Sr--   1 719      124           657 Feb 22  1989 graphics.two/legal.c
> -rw-r-Sr--   1 719      124           892 Mar  3  1989 graphics.two/liggs.c
> cpio: warning: skipped 1247 bytes of junk
> -rw-r-Sr--   1 719      124          3925 Mar 21  1989 graphics.two/omath.cpp
> cpio: warning: skipped 1 bytes of junk
> -rw-r-Sr--   1 719      124         15526 Mar  3  1989 graphics.two/menu.c
> cpio: premature end of file
> 
> so I was hoping there was some way of figuring out why the end of
> file was unexpected and if that means anything is actually missing.

zcat stopped feeding bytes to cpio.  cpio wasn't expecting the end of
the archive to occur at the point that zcat gave up.  You shouldn't
need the "-H" option to cpio when doing copy-in mode.

But you're basicly SOL.  :(  FWIW, you'd probably be just as bad off
had you used gzip and tar.

- Aaron



More information about the NCLUG mailing list