Some weird behaviour about rs-async-zip HOT 4 CLOSED

You aren't doing anything wrong in your example. If I take an archive written via ZipFileWriter::write_entry_whole(), it works perfectly fine.

If you could provide the ZIP file being used, that would be very helpful.
It could just be that it's using some feature of the specification which we don't currently support, and there's not a sanity check for it.

from rs-async-zip.

Yes, I just tried a zip file with an uncompressed txt file to ensure that its not the compression breaking things
Here is a google drive link :)
https://drive.google.com/file/d/1XDp8qIiQn9kNKECEKeoKRHuEGnuoGcKO/view?usp=sharing

from rs-async-zip.

It seems the local file header contains differing extra field data than in the central directory. My assumption was that they'd always be in sync, but that seems to be incorrect based on this spec note:

Extra Field records that MAY contain information about a file that SHOULD
not be exposed SHOULD NOT be stored in the Local Header and SHOULD only
be written to the Central Directory where they can be encrypted. This
design currently does not support streaming.

We currently just seek directly to the data offset using the file name length & extra field length present within the central directory header. So when the two are out of sync, we seek to the wrong place and start reading garbled data.

There doesn't seem to be any way around this other than to always read the local file header as well, which is quite annoying given most of the data is redundant when you have the central directory header.

In the meantime, you could use the read::stream::ZipFileReader implementation as that uses the local file header only.

from rs-async-zip.

okay, thank you! Just for your information, it was a simple zip file I created with 7zip

from rs-async-zip.