8000 macOS and files over 4GB in Finder-created zips · Issue #431 · zlib-ng/minizip-ng · GitHub
[go: up one dir, main page]

Skip to content

macOS and files over 4GB in Finder-created zips #431

Closed

Description

@supersv

Hey Nathan,

Looking at Issue #5 (#5), it seems that the patch didn't make it into the more recent versions (I'm testing with 2.9.0), as the example minizip program is not able to fully extract a zip with large files in it?

The test zip has just 3 files inside - 1-Small, 2-LargeOver4GB, 3-Small - after extracting the second file, it tries to extract the third one, but fails at

else if ((local) && (magic != MZ_ZIP_MAGIC_LOCALHEADER))
        err = MZ_FORMAT_ERROR;

which is at mz_zip.c:218

Any suggestions on how to make the library accept macOS-originating Zip files?

Thanks,
Vasyl

Activity

  1. nmoinvaz commented on Oct 15, 2019

    @nmoinvaz
    Member

    Do you have an example ZIP file?

  2. supersv commented on Oct 15, 2019

    @supersv
    Author

    Sure, here's a zip file with a 5 GB random file (and two small ones) inside, created with Finder:

    https://www.dropbox.com/s/lz2t58ai6gaadlt/MacZipDemo-dev-urandom.zip?dl=0

    Interestingly enough, if the 5 GB file is all zeroes (and gets compressed nicely, to just 5 MB), the extraction works well; sample file:

    https://www.dropbox.com/s/m1sa5avgihm7ssh/MacZipDemo-dev-zero.zip?dl=0

  3. nmoinvaz commented on Oct 20, 2019

    @nmoinvaz
    Member

    I have made some changes that should fix it in dev branch. It will attempt to recover the zip entries in a 4gb zip file that contains no zip64 information.

  4. supersv commented on Oct 21, 2019

    @supersv
    Author

    Thanks for the patch. I've tried recovering the first sample file linked above, with minizip built from dev, but with the same error -103 as the result.

  5. nmoinvaz commented on Oct 21, 2019

    @nmoinvaz
    Member

    I tested against this file.

  6. nmoinvaz commented on Oct 21, 2019

    @nmoinvaz
    Member

    It is working fine for me even with your test file. Not getting -103. I suggest you try and debug the source code and see what the issue is on your end.

  7. supersv commented on Oct 22, 2019

    @supersv
    Author

    Must have been an error on my side - now extraction works on both Mac and Windows. Thanks again.

  8. supersv commented on Oct 23, 2019

    @supersv
    Author

    Found another problem. I'm testing on a zip archive with lots of files inside, among them a single large (> 4 GB) file, created with Finder.

    Situation:

    • commit a44fae3 (before the first 431 fix) - extracts up to the big file, then fails with -103 (as expected);
    • commits be483d8, 28d87dd - fails with -105 on a regular small file (many files before the big file where it failed originally);
    • commits 545d729, 75741f4 - fails the same, with -105, but on a different file, also way before the big file (so behavior has changed after the second 431 fix).

    The failure happens in mz_zip_entry_read_close(), on the zip->entry_crc32 != zip->file_info.crc check.

    I can't share the test zip file in question, but if I manage to create a sample one, I'll post it. This is on a Mac, cmake -G Xcode . and using the resulting minizip -x -d <...> <...zip>.

  9. supersv commented on Oct 23, 2019

    @supersv
    Author

    OK, here's a sample zip file - https://www.dropbox.com/s/pjb2v6s4ltblzu3/protobuf.zip?dl=0

    Basically a clone of https://github.com/protocolbuffers/protobuf with the 5 GB ...-dev-urandom.zip file placed inside protobuf/cmake and compressed with Finder.

    Fails at
    ...
    Extracting protobuf/benchmarks/util/__init__.py
    Error -105 saving entries to disk /.../.../protobuf.zip

    Tested with the current HEAD of dev (75741f4).

  10. Coeur commented on Oct 25, 2019

    @Coeur
    Collaborator

    @supersv do you think that you could come up with a fix?

  11. supersv commented on Oct 25, 2019

    @supersv
    Author

    @Coeur Let's hear Nathan's verdict first.

  12. nmoinvaz commented on Oct 30, 2019

    @nmoinvaz
    Member

    macOS archive utility doesn't write zip files that are 4gb properly with ZIP64 extension. This is a long time known mac bug.

  13. Coeur commented on Nov 4, 2019

    @Coeur
    Collaborator

    @nmoinvaz in that case, I guess I don't need to wait for a fix for that. Do you know how close we are from a minizip 2.9.1 release? I plan to update minizip once you'll be making a release.

  14. nmoinvaz commented on Nov 4, 2019

    @nmoinvaz
    Member

    I was hoping to get to look at these two issues that are open before I do. Maybe I can get to it by next week. I'm currently working on incorporating code coverage into the build system.

  15. nmoinvaz commented on Nov 11, 2019

    @nmoinvaz
    Member

    @supersv the zip file is no longer available..

  16. nmoinvaz commented on Nov 12, 2019

    @nmoinvaz
    Member

    I think I have made a change that could possibly fix it so please test. But the problem is that your zip file contains zip files which make it hard to determine where some entries start and end.

  17. supersv commented on Nov 14, 2019

    @supersv
    Author

    @nmoinvaz Seems to work like a charm. Thanks and congrats!

  18. added
    fixedIssue or bug has been fixed
    zipZIP file format
    on Jan 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fixedIssue or bug has been fixedzipZIP file format

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0