Local file header with no size information about rs-async-zip HOT 3 CLOSED

Could you clarify which part of the crate you're referring to specifically?

When using a data descriptor, the spec dictates that the CRC and (un)compressed sizes should all be zeroed out in the LFH, so it sounds like if we're (somehow) setting a non-zero CRC value, that's the actual issue.

In regard to the reading aspect, main now uses the CDR over the LFH when it can do so (this doesn't currently happen in v0.0.9). So, the only instance of concern would be stream reading combined with a data descriptor - I've since removed the stream reader so it can be re-written but the effects of having to rely on the LFH will certainly be documented when it's added back.

from rs-async-zip.

When using a data descriptor, the spec dictates that the CRC and (un)compressed sizes should all be zeroed out in the LFH, so it sounds like if we're (somehow) setting a non-zero CRC value, that's the actual issue.

No, I was referring to the fact that (in 0.0.9) stream readers did return ZipEntry, which didn't account that it may have no size information available and the caller can't distinguish a non-empty file with a data descriptor from an actually empty file. There are two possible resolutions: have a separate PartialZipEntry type or have ZipEntry::*_size return None when the data descriptor is present but not yet read.

Regarding stream readers: I do have an example of reading a corrupted file in a certain case, but I'm not sure if it's relevant or not given that you are rewriting stream readers anyway.

from rs-async-zip.

Just started to reimplement the stream reader now and have added a clear note on this: d4f2124 (https://ibb.co/QrWtJL4)

Wrapping those three fields within an Option seems cumbersome given how rare the combination of stream reading + data descriptor is, so I'll probably end up just exposing a method returning whether the entry was written with a data descriptor or not.

I'll go ahead and close this for now though.

from rs-async-zip.