Comparing the first zipinfo listing with the most recent, the differences are the following fields offset of local header from start of archive minimum software version required to extract 32-bit CRC value (hex) compressed size uncompressed size All but the "minimum software version required to extract" you would expect to change if you've modified the file. The " minimum software version required to extract" has changed from 2.0 to 1.0, so I assume that is the one you are concerned with. classes5.dex...
The term "version needed to extract" refers to the version of the zip specification and not the version of any zip/unzip implementation. See section 4.4.3.1 of APPNOTE.txt at https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt for the details. That then means you just need an unzip implementation that supports version 2 or better of the APPNOTE.txt specification. I'm not aware of any unzip implementation that doesn't support version 2 of the spec (which was written in the early 1990s) If...
Thanks for the bug report! The Red Hat fix is present in the development version of zip.
There is a patched version of unzip that some of the Linux distros ship that allows the codepage/encoding to be specified. That deals with this use-case. In this case, , specifying codepage 866 with the -O option does the trick $ unzip -l -O cp866 Desktop.zip Archive: Desktop.zip Length Date Time Name --------- ---------- ----- ---- 0 09-28-2016 18:41 Новая папка/ 4 09-28-2016 18:40 Новый текстовый документ.txt --------- ------- 4 2 files
It looks like codepage 866, i.e. Cyrillic
What encoding is used for the filenames in Desktop.zip?
Ta. I'll wait for the official gcc 14.1 & see if I can reproduce the error
Thanks Should have asked upfront, but what platform & C compiler are you running?