David Saez

yes, makes sense, can be closed

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

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

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 the should be appended immediately after the compressed data but there is no compressed data after the central directory

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

I think it's set

ZIP data descriptor not properly supported

ShrinkCompoundFile support for ver.4 format