Some types of ZIP files are packed in "streaming mode", where the data about size and checksum for some headers are only known after the compression ends. This means a Local File Header might have its CRC32 code and size information zeroed out.
ZipParser, however, does not account for this, and will always take the LFH data at face value. This currently causes a EOF error since it tries to decompress into a allocation of empty data (edit: this has now changed to an error message complaining about a zeroed compressed size file instead)
Fortunately, there's a General Purpose Bit Flag for this type of case, which is the bit 3 (mask 0x08) flag, it allows us to indentify that there's a Data Descriptor, which should contain the necessary data to read the entry.
Some types of ZIP files are packed in "streaming mode", where the data about size and checksum for some headers are only known after the compression ends. This means a Local File Header might have its CRC32 code and size information zeroed out.
ZipParser, however, does not account for this, and will always take the LFH data at face value. This currently causes a EOF error since it tries to decompress into a allocation of empty data (edit: this has now changed to an error message complaining about a zeroed compressed size file instead)Fortunately, there's a General Purpose Bit Flag for this type of case, which is the bit 3 (mask 0x08) flag, it allows us to indentify that there's a Data Descriptor, which should contain the necessary data to read the entry.