Incorrect assumption in StoredZipEntry::data_offset about rs-async-zip HOT 3 CLOSED

You're right.. and I've come across this fact before (the spec even suggests to omit the extra_field data for the LFH and only place it in the CDR if it needs to be private - via CD encryption) but somehow forgot about it when doing the re-write.

I would really like to keep the ability to skip reading the LFH in cases like these where it's not really needed, but I don't think there's any way around it. I'll see if I can come up with any clever ideas.

from rs-async-zip.

I'd be curious to see if you come up with something, but it may not be worth the effort.

As far as I know, the LFH + trailing data is usually fairly small (maybe in the range of ~20 to 30 bytes). And it immediately precedes the data you're going to read anyway to decompress the file.

Reading the LFH separately before decompression will cause extra read operations, but there are ways to get rid of those.

For example, you could share a BufReader between the LFH parsing code and the decompression code. In most cases, this should make the reads issued to the underlying reader the same as the current code.

This is because the decompression code currently uses a BufReader with the default buffer size (8kb). Since the the LFH + trailing data is significantly smaller than this buffer size, reading the LFH immediately before decompression shouldn't generally have an impact on the number of reads.

Unfortunately, I don't think there are any clever ways of avoiding reading the LFH in general (I can elaborate more on this with examples if you'd like), but the solution I described above should basically provide equivalent performance characteristics to the current code.

from rs-async-zip.

Just checking if you're okay with something like this.

I'm happy to implement the above solution if you'd like

from rs-async-zip.