Your message dated Fri, 8 May 2009 14:32:24 +0200 (CEST)
with message-id <[email protected]>
and subject line Re: Bug#527388: can't handle zip archives with more than 65535
files
has caused the Debian Bug report #527388,
regarding can't handle zip archives with more than 65535 files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
527388: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527388
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: zip
Version: 3.0-1
Severity: important
zip 3.0 cannot handle zip files with more than 65535 files, e.g.
zip -9ru file.zip directory
gives errors like:
zip warning: expected 10468 entries but found 76004
zip error: Zip file structure invalid (file.zip)
I reported the bug upstream in January, but it seems that nothing has
been done (or Debian is not up-to-date). FYI, I gave the following
testcase:
http://www.vinc17.org/download/archive.zip.bz2
This archive.zip file itself is compressed with bzip2 (1.4 MB),
otherwise this file takes 10 MB.
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26.5-20080922 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages zip depends on:
ii libc6 2.9-10 GNU C Library: Shared libraries
Versions of packages zip recommends:
ii unzip 5.52-12 De-archiver for .zip files
zip suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Thu, 7 May 2009, Vincent Lefevre wrote:
> Package: zip
> Version: 3.0-1
> Severity: important
>
> zip 3.0 cannot handle zip files with more than 65535 files, e.g.
>
> zip -9ru file.zip directory
>
> gives errors like:
>
> zip warning: expected 10468 entries but found 76004
>
> zip error: Zip file structure invalid (file.zip)
>
> I reported the bug upstream in January, but it seems that nothing has
> been done (or Debian is not up-to-date). FYI, I gave the following
> testcase:
>
> http://www.vinc17.org/download/archive.zip.bz2
Ok. I think this is not a bug in zip 3.0 but in zip 2.3, which you
used to create archive.zip.
The traditional zip file format (if you don't use the Zip64 extensions)
is limited to 64K entries. If you managed to create a zipfile with
more that 64K entries using zip 2.3 (which does not support Zip64)
then that's a bug in zip 2.3.
zip 3.0 uses the Zip64 extensions when they are needed, but if the
zipfile is already corrupt, I would not expect it to fix it.
See what "zipinfo -v" (from the upcoming unzip 6.0) says about archive.zip:
Archive: archive.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 10016830 (000000000098D83Eh)
Actual end-cent-dir record offset: 10016808 (000000000098D828h)
Expected end-cent-dir record offset: 10016808 (000000000098D828h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 1465 entries.
[...]
and see what it says if we create archive.zip correctly from the beginning:
unzip archive.zip
zip -r good-archive.zip archive
zipinfo -v good-archive.zip
Output:
Archive: good-archive.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 11222924 (0000000000AB3F8Ch)
Actual end-cent-dir record offset: 11222826 (0000000000AB3F2Ah)
Expected end-cent-dir record offset: 11222826 (0000000000AB3F2Ah)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 67001 entries.
As opposed to zip 2.3, zip 3.0 has no problems adding more entries to
the archive created that way:
$ zip -94u good-archive.zip directory
adding: directory/ (stored 0%)
So the bug was in zip 2.3, which you are not using anymore, not in zip 3.0
which is probably right in refusing to update a corrupted zipfile.
I plan to upload unzip 6.0 in short, but unzip 5.52 is apparently still
able to unzip good-archive.zip.
Thanks.
--- End Message ---
