UpstreamReadError on zip containing another zip about rs-async-zip HOT 7 CLOSED

I've released 0.0.9 so I'll go ahead and close this. 👍

from rs-async-zip.

If the problem was fixed on main, then great. I was planning to use git ref for the dependency, because of the other bug that was fixed here #31.

By the way, do you plan to release new crate version soon?

from rs-async-zip.

Hello, can you provide a reproducible sample file? I've tried zipping some text files and nesting the zip, as well as zipping epubs but sadly I couldn't reproduce this, they all worked well.

In the past I've noticed that some zip files with specific sizes triggered some hidden bugs (because of pre-defined buffer sizes), so a sample file that doesn't work would help a lot, way better than trying arbitrary combinations (which didn't worked for me at least).

Also, I did noticed that your olives.zip has an X in the zipinfo column, which means it contains both an extra field and the extended local header.

This means that the file has extra information and its content wasn't known beforehand, so the Data descriptor was written after the compressed data as well. AFAIK, the most common scenario that a file has an extra field is for Zip64, which isn't supported yet (I did implemented the support, but it still not ready yet and I'm pretty busy those months), but I think that Zip64 is not supported by zip 2.0 since it was only documented in 4.5, so I'm kinda discarding the possibility that it is a zip64 file (even though the error is similar and some zip libraries doesn't follow the spec).

The weird thing is that, if I produce a Zip file similar to yours, even though winrar and file-roller correctly handles it, Ark doesn't and 7z l warns about wrong headers, but async_zip still correctly handles it, unlike your case, so I'm thinking that it may be feeding flate2 with wrong bytes, the only way to know is having a failing zip I can test and debug.

from rs-async-zip.

Thanks for looking into that. Here are two files that I was using for testing:
with-zipfile.zip
with-epub.zip

First is the one containing zip compressed jpg and the second one contains an ebook.

But there is something related to the fact how the zip files have been created. My OS is Linux Fedora and I created the zipfiles using Nautilus file browser. When I create the zipfile using zip, commandline:

$ zip -r with-zipfile2.zip with-zipfile/

the async_zip decompresses the contents without issues. Judging from that fact, it must be something with the extra flags you mentioned.

P.S. Previously I didn't include the deps, so here we go:

[package]
name = "test_zip"
version = "0.1.0"
edition = "2021"

[dependencies]
async_zip = "0.0.8"
tokio = {version = "1.20.1", features = ["full"] }

from rs-async-zip.

Interesting, I've tested both zips and they fail on 0.0.8, but it seems like it's already fixed by #28, try using the latest version from git:

[dependencies]
async_zip = { git = "https://github.com/Majored/rs-async-zip" }

And see if it helps.

Even though it's not the best advice to get the dependency directly from git/vcs, it may be a valid solution for the mid-term, at least until the next version is released. You can also pin a specific revision which guarantees it doesn't get a newer (and maybe incompatible) revision:

[dependencies]
async_zip = { git = "https://github.com/Majored/rs-async-zip", rev = "0f4bf7f09d2fef1236924a6af45a5641392faf6b" }

from rs-async-zip.

A new crate version would be great. I am using the crate in a library I am making but I can't publish it using the git dependency. Version 0.0.8 is not working because of #28.

from rs-async-zip.

I have some freed-up time now to start working on this crate again.

Over the last few days, I started working on a new ZipEntry structure for interoperability between the reading and writing sides of the crate. Once that's done, I'll release a new version.

@JonathanxD Thanks again for the original fix & looking into this issue.

from rs-async-zip.