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
{{ message }}
Repository navigation
Feature request: Add support for writing raw entries like in 1.2 #217
It seems that minizip 2.0+ no longer has the ability to write raw (pre-compressed) entries to a zip file. My main use case is copying files from one zip file to another, making changes to certain entries in the process. With minizip 1.2, It was possible to directly copy the compressed data from one file to the other to avoid the CPU overhead of decompression + recompression. This was done by passing 1 for the raw parameter in the unzOpenCurrentFile2 and zipOpenNewFileInZip2_64 functions.
Are there plans for implementing this in minizip 2.0 as well?
I used the gist you created (thanks btw!) and tested it against some zips that I created with WinRAR and wasn't able to reproduce those results. I tested a zip with a single file and one with multiple files. Can you try and narrow down what might be the cause? If you delete the output file and try the test again, does it work then? Thanks.
Hmm, that's inter
E45E
esting. Maybe it's a Linux specific issue? I just tried extracting the original zip, packing it again with 7zip, and this time, minizip created a 9.9 GB file. It doesn't seem to matter if I delete the output file first or not.
Sorry, that was caused by my own mistake. I deleted the post. I accidentally built the library with -DHAVE_AES and my test program without that, so the structs did not match.
Activity
nmoinvaz commentedon Jan 2, 2018
I believe
mz_zip_entry_read_openhas a raw parameter and formz_zip_entry_write_open, use 0 as the compress_level.chenxiaolong commentedon Jan 2, 2018
@nmoinvaz Thanks! I gave that a try but it seems to produce a zip that's much larger than the original.
Sample code that copies compressed data from one zip to another: https://gist.github.com/chenxiaolong/bcbb0835182ef16a25f09db8d99e0619
nmoinvaz commentedon Jan 2, 2018
I used the gist you created (thanks btw!) and tested it against some zips that I created with WinRAR and wasn't able to reproduce those results. I tested a zip with a single file and one with multiple files. Can you try and narrow down what might be the cause? If you delete the output file and try the test again, does it work then? Thanks.
chenxiaolong commentedon Jan 2, 2018
Hmm, that's inter E45E esting. Maybe it's a Linux specific issue? I just tried extracting the original zip, packing it again with 7zip, and this time, minizip created a 9.9 GB file. It doesn't seem to matter if I delete the output file first or not.
Not sure if it helps at all, but these are the zips I was testing with:
Original: https://noobdev.io/github/minizip/217/foobar.zip
Repacked with 7zip: https://noobdev.io/github/minizip/217/foobar.7zip.zip
Fixed bug reading entries with 0 size. #217
nmoinvaz commentedon Jan 2, 2018
Looks like it was a bug reading entries that are 0-byte. Should be fixed now. Thanks.
chenxiaolong commentedon Jan 2, 2018
Thank you! It's looking good in my initial testing. I'll try a couple more things and then close this issue if everything works.
chenxiaolong commentedon Jan 3, 2018
Everything is looking good with respect to copying raw entries now. Thanks again for fixing this.
nmoinvaz commentedon Jan 3, 2018
Compression method 99 is used for AES encryption. Are you using encryption now?
chenxiaolong commentedon Jan 3, 2018
Sorry, that was caused by my own mistake. I deleted the post. I accidentally built the library with
-DHAVE_AESand my test program without that, so the structs did not match.