You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: