Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with zipOpenNewFileInZip2_64() in Minizip #799

Open
yliu-MW opened this issue Apr 6, 2023 · 0 comments
Open

Issues with zipOpenNewFileInZip2_64() in Minizip #799

yliu-MW opened this issue Apr 6, 2023 · 0 comments

Comments

@yliu-MW
Copy link

yliu-MW commented Apr 6, 2023

Dear Minizip folks,

I am running into issues with the zipOpenNewFileInZip2_64() API. In particular, I use this API to open a file in zip and use zipWriteInFileInZip() to write data into the file. When I specify the "zip64" argument in zipOpenNewFileInZip2_64() to 1 and the size of the data I actually write into the file is less than 4GB, the compressed size and uncompressed size in the zip64 extended block fields of that file are all zeros. But the compressed and uncompressed sizes in the local file header show up correctly. This causes a mismatch (i.e., the sizes in the zip64 extra blocks are different from the sizes in the local file header) which breaks the Microsoft packaging API: https://learn.microsoft.com/en-us/windows/win32/api/msopc/.

In my understanding, the expected behavior of zipOpenNewFileInZip2_64() should be as follows: when zip64=1 and the uncompressed size turns out to be less than 4GB, it will change the file from zip64 back to zip32 by changing the minimum version required to extract, deleting the zip64 extra fields, etc. Only when zip64=1 and the size turns out to be larger than 4GB will the output file be in zip64. This is also what 7zip appears to do.

May I ask if you can fix this issue with the zipOpenNewFileInZip2_64() API?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant