#19 ZIP64 support

Eric Trinh

Here is a proposal patch for zip64 support.
It uses vanilla minizip 1.1 (crypt.h, ioapi., zip., unzip.*) (I moved patches inside quazip).
There is no DataDescriptor writing option support, and write/read are still limited to 32bit buffers.
Best Regards,

1 Attachments


  • Sergey A. Tachenov

    Well, thank you, but I still need to reimplement those changes specific to QuaZIP and I also need to do something about the ABI - as it is, your patch breaks it. I understand that I can't keep the ABI fully compatible, so I guess I need some compile-time defines that can control this: either the user gets zip64 support or the backwards compatibility with previous versions of QuaZIP.

    As I understand, that *_64() minizip functions you use in your patch will produce zip64-enabled ZIP file even if no file actually exceeds the limit? Will those files still be compatible with other 3rd-party libraries?

  • Eric Trinh

    Eric Trinh - 2014-01-16

    In fact it is the zip file open function to create item in minizip which has a zip64 flag (0/1) to produce a Zip64 (I set it always to 1, so maybe there may be incompatibility issues with older systems). It could be better set in Quazip.
    I haven't tested with a lot of third party software, but 7zip, winzip and windows7 open fine.

  • Sergey A. Tachenov

    Well, first of all thanks for the nice patch. I didn't apply it, but it gave me a rough idea of what needed to be done to implement the zip64 support.

    Now the trunk contains my version of what is very similar to your patch. The zip64 mode is enabled by calling QuaZip::setZip64Enabled() (for writing) and providing an instance of QuaZipFileInfo64 (for reading) to the appropriate methods (old QuaZipFileInfo is still 32 bit for compatibility).

    The backwards compatibility seems to be OK, but zip64 support looks somewhat broken in Minizip 1.1. I tried to create a simple archive in zip64 mode (with a small file) and it looks weird - the zip64 extra field is created, but it's only 16 bytes long which are all zero, then in the local header there are correct 32-bit sizes which should be 0xFFFFFFFF if the extra field is present according to APPNOTE.TXT. It still opens OK with 7-zip and Linux unzip command. Weird.

  • Sergey A. Tachenov

    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks