patch: unzip succeeds with CRC errors

[Paul Fox]

 > >  > > i assume unzip should return failure in the presence of
 > >  > > crc errors, correct?  i'll apply this unless there are
 > >  > > objections.
 > >  > 
 > >  > It should return failure, but not exit immediately. A corrupt file you
 > >  > can try to recover data from is better than no file at all..
 > > 
 > > the errors are detected at file granularity -- so if you are trying to
 > > unzip the whole archive, unzip will now stop after (fully extracting)
 > > the first bad file, and won't process the rest of the archive. 
 > > any individual file can still be extracted on its own, with
 > > resulting success or failure.
 > > 
 > A small user comment...
 > Is that logic required?

it's not "required", it's just what currently happens.  the only
change being proposed to unzip.c is that it fail when it detects
a file with bad CRC.  currently, it reports the error (via message
only) and then completes successfully, making it unscriptable.

 > 
 > If you are going to stop after detecting a bad file crc, why leave 
 > the bad file on the filesystem?

as someone pointed out above, sometimes bad data is better than no
data.

 > 
 > If you are going to leave the file on the filesystem - why not mark it
 > as failed (your choice of marker) and just continue?  

example?  by "marker", you mean "print a message"?

 > 
 > Why make the user dig through the catalog of files in the archive and 
 > extract them by name after a bad file crc?
 > 
 > Why not use logic similar to that of 'patch'? Just mark failed files
 > and continue to process the balance of the archive.
 > Much easier on the end-user that way.

i agree.  it would be easier on the user, and not too hard for
someone to add to the current code.  but in my current use case,
what you propose wouldn't necessarily be better -- the current
"no error failure" behavior was discovered during a "hidden"
product upgrade process, where the user is only interested in
blanket success or failure -- they never see the unzip happen.
in this case, extracting everything just delays the inevitable
failure.

note also that it's only in the case of bytes simply changing
values that subsequent files will be unaffected.  if bytes are
missing or added, i don't believe there's a way to extract
subsequent files, even if they themselves are okay.

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.

paul
=---------------------
 paul fox, pgf at brightstareng.com