[BusyBox] unzip.c: change "accept" to "zaccept"

[Paul Fox]

hello whylee --

 > 
 > Hi Paul!
 > 
 > A few days ago i tested the unzip from the tagged version
 > busybox_1_00_rc3.  It showed the same behavior as the

why are you working with rc3?  busybox 1.00 was released a long
time ago.

 > busybox_1_00_pre8.  i think about 95% of our zip-archives are
 > working good but a few zipped files show the error "Invlaide
 > zip magic" while unzipping.
 > 
 > I don't know, if there is a bug in the old
 > busybox-unzip-source-code or is there a bug in the zip-file (i
 > think it was buildt with a pkzip under dos).  Maybe this bug
 > only comes to light when busybox runs on our arm7 (big-endian
 > vs.  little-endian troubles???)

the busybox simply unzip cannot deal with certain formats of zip
files.  the patches i applied on 7/20 fix a lot of things, but
not that.

the zip format allows for the lengths of the component members to
be stored either along with each member, or at the very end of
the archive.  many zip programs will put the lengths only at the
end, since when writing the archive, this is the easiest thing to
do.  however, when you read such an archive, you need to seek to
the end (and account for block padding which may have been
applied there), and find the "header" (i guess it's really a
trailer) in order to get the component lengths.  busybox unzip
doesn't do this.  as a result, when it reads the archive, it
finds a zero length in the per-component header for every
component, and incorrectly expects to find the next component's
header immediately after the previous.  this results in the
"invalid magic" message that you see.

clearly at a minimum busybox unzip should notice that the
component length is zero, and if the next magic is bad, it should
emit a more explanatory message than it does now.

if anyone is tempted to _really_ fix this, _please_ don't break
one of the nice features of the busybox implementation --
currently, it does no seeking, and therefore can do all of its
work when the archive is being piped to it.  so although it can't
read all archives, the ones that it _can_ understand can be read
in a way that the more correct zip programs cannot do.

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