#2469 ZIP data descriptor not properly supported

[David Saez]

When extracting a zip file where size and crc are set on a data descriptor block following file contents, 7zip is able to extract files but complains about header errors

Data descriptor

If the bit at offset 3 (0x08) of the general-purpose flags field is set, then the CRC-32 and file sizes are not known when the header is written. If the archive is in Zip64 format, the compressed and uncompressed size fields are 8 bytes long instead of 4 bytes long (see section 4.3.9.2[34]). The equivalent fields in the local header (or in the Zip64 extended information extra field in the case of archives in Zip64 format) are filled with zero, and the CRC-32 and size are appended in a 12-byte structure (optionally preceded by a 4-byte signature) immediately after the compressed data:

Using 7Zip 24.04 beta 64-bit for Windows x64 on Windows 11
Sample file attached

[Igor Pavlov]

Bit 3 in central directory records is not set.
So if we read central directory, we don't see that archive uses descriptors.

Try to find software that was used to create that zip archive, and ask developers of that software to fix their code.

[David Saez]

I think it's set

[Igor Pavlov]

It's local header.
It's not central directory.
Central directory is at the end of the archive.
7-zip checks that bit 3 is same value in both local header and central directory.
So 7-zip can show that there are minor errors in archive headers.

What software was used to create that zip archive?

[David Saez]

zip file is created by us (own software)

in central directory both length and crc32 are set so it should not need bit 3 to be set and the extra data descriptor

i cannot fins any documentation that says that when bit 3 is set in the file header it must also be set in central directory

[David Saez]

also it will not make any sense to add several data descriptor blocks after the central directory, they will be redundant and the docs says data descriptor should be appended immediately after the compressed data but there is no compressed data after the central directory

[Igor Pavlov]

APPNOTE:

Bit 3: If this bit is set, the fields crc-32, compressed 
               size and uncompressed size are set to zero in the 
               local header.

   4.4.8 compressed size: (4 bytes)
   4.4.9 uncompressed size: (4 bytes)

If bit 3 of the general purpose bit flag is set, 
       these fields are set to zero in the local header and the 
       correct values are put in the data descriptor and
       in the central directory.               

There is no descriptor in central directory. But central directory still supports bit 3.
That bit 3 in central directory allows the decoder to know that desrcriptor is used, even if decoder reads only central directory for listing.
For example, 7-Zip reads central directory and 7-zip shows in archive properties that descriptors are used by archive.

Look another zip encoders. And these another zip encoders write same value for bit 3 to local header and to central directory.
So probably only your software doesn't write it.

[David Saez]

ok, other decoders that do not have this problem also seems to have no problems if bit 3 is set in the central directory

[Igor Pavlov]

7-zip decoder is more strict than other decoders.
So 7-zip can allow to find problems as this problem in your software.

Correct bit 3 in central directory is useful, because it's important information about encoding scheme.
So encoders should write it, as I suppose.

If all zip encoders (except of your encoder) write that bit to central directory, I suppose we should try to keep more compatibility with them.
Why to write some unusual value, if we don't understand fully the sentence:

Bit 3: If this bit is set, the fields crc-32, compressed 
               size and uncompressed size are set to zero in the 
               local header.

we can treat it also in reverse order also:

`if compressed 
               size and uncompressed size are set to zero in the 
               local header` when descriptor is used, then `this bit 3 is set`.

It was not written so in specification, but it could be supposed.

[David Saez]

yes, makes sense, can be closed