As the README says:

Unfortunately, due to a lack of time and loss of interest, this project will no longer be actively maintained.

Since zip-rs crate is widely used(crates.io reverse dependencies show 120), how about moving this repository to a GitHub organization or add collaborators to this repository and let the community maintain this crate?

The copy is done directly using the raw compressed data, avoiding decompression and recompression.

In summary, the changes:

• Add a private API for ZipFile to get the raw stream that doesn't do any CRC check or decompression.
• Add the copy_file and copy_file_rename to ZipWriter that use that raw stream to copy the file.

I get nearly 95% faster Zip file modifications when I copy nearly all files, and just ignore the files I am removing from the Zip.

closes #95

This is now in a good state. ~~To be clear, this only implements async zip reading, writing is not added in this PR~~.

Fixes https://github.com/zip-rs/zip/issues/124

Hello Maintainer,

Firstly, thank you for creating and maintaining this library!

Secondly, are you interested in adapting this library to support concurrent reads?

For my application, I need to read entries (at random) from a zip file over an extended period of time. The reads might be concurrent, and might be interleaved (read a few bytes from zip entry A, then a few bytes from zip entry B, then A again, etc).

The current API shape makes this use-case impossible without creating multiple ZipArchives.

I've hacked the code to accomplish my goals, and thought I'd share it here in case you or any library users are interested in doing something similar.

I'd rather not maintain a separate fork of this library just to suit my use-case if it can be avoided, so if there is interest in incorporating any kind of support for concurrent reads, I'm happy to help out.

If there is no interest, please don't hesitate to close this issue.

    let zip_file = fs::File::open(PATH)?;
    let zip = ZipArchive::new(&zip_file)?;
    let mut files = vec![zip.clone(); zip.len()];
    let mut files: Vec<_> = files
        .iter_mut()
        .enumerate()
        .map(|(i, file)| file.by_index(i).unwrap())
        .collect();
    files.iter_mut().for_each(|x| {
        let mut s = String::new();
        x.read_to_string(&mut s).unwrap();
        println!("{}", s);
    });

`Err` value: Custom { kind: Other, error: "Invalid checksum" }

panicked at x.read_to_string(&mut s).unwrap();

This PR adds support for decrypting AES encrypted zip archives (compression method 99). It implements the special non-NIST variant of the CTR mode used by WinZip, but otherwise uses off-the-shelf crypto crates.

The feature itself is hidden behind an aes feature flag. We will leave it up to upstream to enable or disable it and/or mention it in the docs.

Encryption can be added if desired, as the decryption methods can be used to encryption as well.

This is more of a question than it is a bug, I'm sure. Given the following code:

fn index(req: &HttpRequest) -> FutureResponse<HttpResponse> {
  // Get the zip file in the form of bytes
  return req
    .body()
    .limit(512000)
    .from_err()
    .and_then(move |b: Bytes| {
      println!("{:?}", b);

      let mut archive = zip::read::read_zipfile_from_stream(&mut b).unwrap(); // <- error here.

      Ok(HttpResponse::NoContent().into())
    })
    .responder()
}

Obviously I do not have an actual stream, but I do have the bytes. How can I create an archive purely from bytes? I've looked into stdin, but that doesn't quite fit the bill. I'm trying to read an archive that's being sent in the form of a curl request. Is there some way I can achieve this with my current code as the framework?

If you run

cargo +nightly update -Z minimal-versions && cargo +nightly check

on this project (and require at least [email protected], since that crate has a similar bug), you should see the build fail with multiple errors like this one:

error[E0277]: `?` couldn't convert the error to `ZipError`
   --> […]\.cargo\registry\src\github.com-1ecc6299db9ec823\zip-0.5.9\src\write.rs:713:35
    |
668 | fn write_central_directory_header<T: Write>(writer: &mut T, file: &ZipFileData) -> ZipResult<()> {
    |                                                                                    ------------- expected `ZipError` because of this
...
713 |     writer.write_all(&extra_field)?;
    |                                   ^ the trait `From<std::io::Error>` is not implemented for `ZipError`
    |
    = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
    = note: required by `from`

error: aborting due to 137 previous errors

It seems that thiserror introduced a new feature between versions 1.0.6 and 1.0.7 without increasing their minor version.

I suggest specifying

thiserror = "1.0.7"

and, ideally, yanking all affected versions.

Hi. When using compression (CompressionMethod::Bzip2 / CompressionMethod::Deflated), some files in the archive are broken. (examples of files in the attachment)

If you use CompressionMethod::Stored, files are saved correctly

example.zip broken_archive.zip

use std::fs::File;
use zip::CompressionMethod;
use zip::write::FileOptions;
use zip::write::ZipWriter;

let files = vec!["file1", "file2"...];
let arc_opt = FileOptions::default().compression_method(CompressionMethod::Deflated);

let cursor = Cursor::new(Vec::new());
let mut archive = ZipWriter::new(cursor);

files.iter().for_each(|file| {
    archive.start_file(&file, arc_opt.clone()).unwrap();

    let mut file_buf = vec![];

    File::open(file).unwrap().read_to_end(&mut file_buf).unwrap();

    archive.write(&file_buf).unwrap();
}

let data = archive.finish().unwrap();

File::create(&archive_path).unwrap().write_all(data.into_inner().as_ref()).unwrap();

Features flags do not affect the result:

zip = "0.5"

zip = { version = "0.5", features = [ "deflate-zlib", "deflate-miniz" ] }

Am I missing something? Thanks for the any help.

PR #290 (rev a1da6860ea423e999b731fca866ed54505e0096e) appears to have broken writing, at least header writing. Creating test.zip by my example code in #287, tools report:

7-Zip:

Error: Headers Error
Unconfirmed start of archive

Warning: Headers Error
There are some data after the end of the payload data

zip -T test.zip (zip 3.0-11build1 on Ubuntu 20.04):

  error:  invalid compressed data to inflate testfile
test of test.zip FAILED

zip error: Zip file invalid, could not spawn unzip, or wrong unzip (original files unmodified)

Neither 7-Zip nor unzip can extract the archive created by this library.

The same code, when using rev 574bb3df1748a89c8cb1dbed65e625526e4496ee, the immediately preceding commit, creates a working ZIP file.

Added two new functions to the API ( resolves #64 ):

ZipArchive::by_name_decrypt
ZipArchive::by_index_decrypt

These functions behave identically to their already existing counterparts without _decrypt, but take a password in the form of &[u8]. The password is not a &str because the ZipCrypto standard does not define which encoding is used, so UTF-8 cannot represent all possible passwords (for details, please read the comments in zipcrypto.rs).

The functions integrate seamlessly with the existing API. Substantial restructuring was necessary to insert the CryptoReader between the other readers. The code has been modified to facilitate the addition of further crypto or decompression routines.

Note that the API for read_zipfile_from_stream does not yet support ZipCrypto reading. However, this is not hard to add. Also, ZipCrypto writing support has not been added at this point in time. I want to make sure that my work is in line with what the authors and the users expect before I continue working on this.

In addition to that, a ZipCrypto writer will need cryptographically secure randomness (even though the crypto is weak). Where this notoriously hard to get randomness comes from is up for discussion.

fixes #283

This brings the changes made by @rushiiMachine to support in-place deletion.

I tried my best to keep original authorship, but I fixed a couple tests, documentation and formatting. I'm also adding a test for file deletion on top of @rushiiMachine 's work.

I left these enabled in dev-dependencies, so that the tests still work, but to be honest, I don't think those tests are really useful.

The reason to disable this is the proc macro stuff has a significant build time impact, and it's not really something zip users need.

Hi there,

I'm using this crate in something that uses zips as a backup medium, where I'm looking to compare timestamps of files between zips etc.

So I can use this crate to save the timestamp into the zip correctly using options.last_modified_time & other apps (e.g. Finder) will extract the files out with the metadata attached -- but when I'm using archive.extract all the files are given a last_modified timestamp of whenever the extract happened.

Not sure if there's an option on extract that I'm missing?

Thanks

I think it could be beneficial to have some to_owned method here and possibly elsewhere? Or is there perhaps a more fundament way of doing this?

https://docs.rs/zip/latest/zip/read/struct.ZipArchive.html#method.by_index

fn by_index2(self, file_number: usize) -> ZipResult<OwnedZipFile>

When using bzip2 with compression level 0, it panics with this error:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `-2`,
 right: `0`', /home/test/.cargo/registry/src/github.com-1ecc6299db9ec823/bzip2-0.4.3/src/mem.rs:123:13

According to docs, 0 is allowed for bzip2: https://docs.rs/zip/0.6.3/zip/write/struct.FileOptions.html#method.compression_method