patch: unzip succeeds with CRC errors

[Jason Schoon]

On 3/27/06, Paul Fox <pgf at brightstareng.com> 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").
>
> have you looked at the code since this topic came up?  (the other
> day you said that you had not.)  currently unzip dies immediately for
> every error condition _except_ CRC failure:  write failures,
> mismatched node types, unsupported compression methods, failure
> to read zip headers (which might be the result of a previous
> corrupted archive member which would have reported a CRC error),
> etc.  all i'm proposing is adding "CRC failure" to the list of
> conditions which cause immediate exit.
>
> i'll hold off on committing this, but i'm also not going to take
> on the "make unzip tolerant of various mid-stream errors" task,
> with the requisite testing.


I like the  correlation that somebody made to patch.  I would think unzip
should extract as many files as possible, and both print out a failure, and
return a failure code, if a CRC has failed.  The return code keeps scripted
processes from silently failing, while extracting all good files is more
desirable for interactive usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20060327/30ffa21c/attachment-0002.htm