#1019 Wrong 'version need to extract' field in the zip header

[Cavarretta Fulvio]

When creating a zip file, in the the 'Local file header' section, 7zip code a wrong 'version needed to extract' filed.
In fact, instead of using the zip specification version needed to extract the created file, 7zip code the 7zip version used to create the archive; this is wrong according to zip specifications (http://www.pkware.com/documents/casestudies/APPNOTE.TXT, section V.J. Explanation of fields )
See CPP/7zip/Archive/Zip/ZipAddCommon.cpp file SetCoderProperties method MY_VER_MAJOR MY_VER_MINOR macros.

[Igor Pavlov]

It uses MY_VER_MAJOR only for

LZMA Version Information - this field identifies which version of
the LZMA SDK was used to compress a file. The first byte will
store the major version number of the LZMA SDK and the second
byte will store the minor number.

So why do you think that it's incorrect?

[Cavarretta Fulvio]

If I'm not mistaking, the zip specification says that th field should contain the zip specification version needed to extract the zip content, not the version of the compressor used.
Now if you perform the hexdump of a zip file created with 7z you have:
50 4b 03 04 14 03 00 00 .....
The first 4 bytes are local file header signature, while the second 2 bytes are the version needed to extract.
If you convert 10 03 int decimal, you get 788 (which is a not existing spec. version) and not 20 (..a more reasonable one), as expected.

I thought that this was coded inside ZipAddCommon.cpp but I was wrong.
Sorry for the wrong source signaled, anyway to me it seems that the zip header is somewhere wrongly coded.

Thank for your attention.

Fulvio

[Igor Pavlov]

show full log:

dir a.txt > log.txt
7z a a.zip a.txt >> log.txt

and check 7z.dll (version of 7z.dll engine).

[quanta]

According to the APPNOTE.TXT - .ZIP File Format Specification version 6.3.2[1], the lower byte in the 'version needed to extract' field should be set to 63 (in decimal) if the file is compressed with LZMA, not 788 or even 20.

[1] http://www.pkware.com/documents/casestudies/APPNOTE.TXT

[Igor Pavlov]

goldart_geo:

I'll fix it. Thanks!

[IBBoard]

I've just tripped across this because of an old version of SharpZipLib and some files created by p7zip. SharpZipLib 0855 errored with "Version required to extract this entry not supported (788)". From looking at the spec then this is actually correct - 0x14 0x03 means "version 2.0 of the spec" and "Unix line record format". The default for the second byte is 0x00, and some tools assume that it will always be 0x00, incorrectly using the value as a little-endian Int16 and rejecting p7zip's value. SharpZipLib 0860 now handles it correctly.

Hopefully that helps some other people who trip over the same error with tools like SharpZipLib rejecting values of 788 :)