patch: unzip succeeds with CRC errors

[Rob Landley]

On Monday 27 March 2006 1:58 pm, Paul Fox wrote:
> me:
>  > > i'm going to commit the two line change i have now since i believe
>  > > it's a necessary first step, no matter what else is done.
>
> rich felker wrote:
>  > No it's not. The correct fix is to set an error flag, then check the
>  > error flag on exit and exit with failure status if it's set. Exiting
>  > as soon as a CRC failure is detected is a regression.
>
> correctly reporting failure hardly seems like a "regression" to
> me, though granted, you're probably coming at this from an
> interactive use point of view ("dammit, i want as many files as i
> can get"), and i'm coming at it from the point of view of
> scriptability ("it failed.  stop now").

What does "tar" do?

I lean towards thinking that if you want to do forensic work on damaged zip 
files, the full info-zip package might be a good idea.  Busybox has always 
focused on "good enough for 99.9% of the cases, and not behaving stupidly the 
rest of the time".  99% of the time a damaged archive file means you have 
junk, unless you're a data recovery service.  It either means your physical 
media is failing (and thus probably took out a fairly large chunk, since hard 
drives and cds have their own built-in crc these days), or else it was 
garbled in transit meaning it's pretty likely the length changed which means 
how does it find where the later files _start_ in the archive?  (Again, you'd 
need something like zipfix.)

Back in the days of dos, it was possible for single bit errors to bubble up to 
the user.  If that happens now, you have bad memory without ECC or the 
ability to catch a machine check exception.  Has anybody actually _seen_ this 
in the past 10 years?  (That would be since 1996.)

Rob
-- 
Never bet against the cheap plastic solution.