#48 Corrupt 64bit zip when adding more than 65k files

[Ronald Ammann]

I compared the original zip.c with your modification and realized that one check is missing. In this case the 64bit header is not written, and other tools can't open the (corrupt) zip.

So in zipClose() you need to check for zi->number_entry > 0xFFFF too. Here's the diff:

diff --git a/quazip/zip.c b/quazip/zip.c
index 75d4f75..e388d54 100644
--- a/quazip/zip.c
+++ b/quazip/zip.c
@@ -1973,7 +1973,7 @@ extern int ZEXPORT zipClose (zipFile file, const char* global_comment)
     free_linkedlist(&(zi->central_dir));

     pos = centraldir_pos_inzip - zi->add_position_when_writting_offset;
-    if(pos >= 0xffffffff)
+    if(pos >= 0xffffffff || zi->number_entry > 0xFFFF)
     {
       ZPOS64_T Zip64EOCDpos = ZTELL64(zi->z_filefunc,zi->filestream);
       Write_Zip64EndOfCentralDirectoryRecord(zi, size_centraldir, centraldir_pos_inzip);

[Sergey A. Tachenov]

Compared to what? In the original zip.c (Minizip 1.1), there's exactly that. Do you have another (newer) version of minizip? Perhaps there are another checks to be made.

Thanks for this one, though. Committed in r239.

[Ronald Ammann]

I compared to minizip contrib in zlib. As far as I can tell there are no other missing checks.

[Sergey A. Tachenov]

Awesome. I had no idea that the Minizip version at winimage.com wasn't the latest one. I have just compared them, and it seems that there are no major differences except one another check, but that one I have already implemented myself in my copy of zip.c when I was porting QuaZIP to Minizip 1.1.