feat: add ZipFileData to public API

[Kinrany]

Hello, I noticed that HasZipMetadata returns an unnamed type, making it inconvenient to pass around separately from the underlying ZipFile.

My use case is filtering files based on their metadata before retrieving their contents from the archive. I'd like to have a function that accepts impl Fn(&ZipFileData) -> bool.

I see that there is a test, test_explicit_system_roundtrip, which mentions ZipFileData being unnamed in the public interface. On the other hand the name is about the only thing not public about ZipFileData, e.g. one is free to create new instances of it via Default. So I fail to infer whether it being unnamed is really intended.

Apologies for the brevity of the PR; hopefully the change is small enough that accepting/rejecting/requesting changes is little effort.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR updates the crate’s public API exports by re-exporting an additional type from the read module.

Changes:

• Re-export ZipFileData alongside HasZipMetadata from crate::read.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gemini-code-assist]

Code Review

This pull request updates the public exports in src/lib.rs to include ZipFileData via the read module. The reviewer identified that this change will result in a compilation error because ZipFileData is not currently exported from the read module, and provided a code suggestion to export it directly from crate::types instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

This change will cause a compilation error because ZipFileData is not publicly exported from the read module (crate::read). In src/read/mod.rs, ZipFileData is only imported privately via use crate::types::ZipFileData;.

To fix this, you can either:

1. Re-export ZipFileData directly from crate::types in src/lib.rs (consistent with how DateTime or System are exported).
2. Or, if you want it to be accessible via zip::read::ZipFileData as well, you must also modify src/read/mod.rs to publicly export it (pub use crate::types::ZipFileData;).

Suggested change

	pub use crate::read::{HasZipMetadata, ZipFileData};
	pub use crate::read::HasZipMetadata;
	pub use crate::types::ZipFileData;

[Its-Just-Nans]

My use case is filtering files based on their metadata before retrieving their contents from the archive. I'd like to have a function that accepts impl Fn(&ZipFileData) -> bool.

Hi,

Which field do you need to access ?

Your function could take a ZipFile ?

[Kinrany]

The issue with ZipFile is that it's generic over the reader, which massively complicates the closure's trait bounds.

[Its-Just-Nans]

And which field do you need to access ?

[Kinrany]

As for my use case, I currently just want the name of the file, be it UTF-8 or not.

[Its-Just-Nans]

As for my use case, I currently just want the name of the file, be it UTF-8 or not.

Are you not using name_raw() or name() of ZipFile ?

https://docs.rs/zip/latest/src/zip/read.rs.html#808-810

btw in the next version, the name will not be part of ZipFileData anymore

Better start using name_raw() or name() I think !

[Kinrany]

Yeah, what I'm doing now is restricting filters to UTF-8. The closure just provides a &str. But that's both somewhat likely to need to change in the future, which I'd like to avoid (especially if something like this makes it into my own public API), and also not as clear as "you get the archive's metadata" and requires a bit more documentation.

[Its-Just-Nans]

Yeah, what I'm doing now is restricting filters to UTF-8. The closure just provides a &str. But that's both somewhat likely to need to change in the future, which I'd like to avoid (especially if something like this makes it into my own public API), and also not as clear as "you get the archive's metadata" and requires a bit more documentation.

You can do

use zip::HasZipMetadata;

fn filter(zip_file: &impl HasZipMetadata) -> bool {
    // a random condition
    zip_file.get_metadata().crc32 > 0
}

fn main() {
    use std::io::Cursor;
    use std::io::Write;
    use zip::CompressionMethod::Stored;
    use zip::ZipArchive;
    use zip::ZipWriter;
    use zip::write::SimpleFileOptions;

    let mut writer = ZipWriter::new(Cursor::new(Vec::new()));
    let options = SimpleFileOptions::default().compression_method(Stored);

    let filename = format!("test.txt");
    writer.start_file(&filename, options).unwrap();
    writer.write_all(b"content").unwrap();

    // Write and read back
    let bytes = writer.finish().unwrap().into_inner();
    let mut reader = ZipArchive::new(Cursor::new(bytes)).unwrap();

    let file = reader.by_index(0).unwrap();
    if filter(&file) {
        println!("OK");
    }
    println!("DONE");
}

[Kinrany]

Yeah, but we can't have Fn(&impl HasZipMetadata) -> bool because closures can't be generic.

[Its-Just-Nans]

Yeah, but we can't have Fn(&impl HasZipMetadata) -> bool because closures can't be generic.

use zip::HasZipMetadata;

fn main() {
    use std::io::Cursor;
    use std::io::Write;
    use zip::CompressionMethod::Stored;
    use zip::ZipArchive;
    use zip::ZipWriter;
    use zip::write::SimpleFileOptions;

    let mut writer = ZipWriter::new(Cursor::new(Vec::new()));
    let options = SimpleFileOptions::default().compression_method(Stored);

    let filename = format!("test.txt");
    writer.start_file(&filename, options).unwrap();
    writer.write_all(b"content").unwrap();

    // Write and read back
    let bytes = writer.finish().unwrap().into_inner();
    let mut reader = ZipArchive::new(Cursor::new(bytes)).unwrap();

    let filter = |z: &dyn HasZipMetadata| {
        z.get_metadata().crc32 > 0
    };

    let file = reader.by_index(0).unwrap();
    if filter(&file) {
        println!("OK");
    }
    println!("DONE");
}

[Kinrany]

Haha, yes, fair!