| Crates.io | vfs-zip |
| lib.rs | vfs-zip |
| version | 0.2.1 |
| created_at | 2020-09-01 17:38:54.7567+00 |
| updated_at | 2020-09-09 00:24:32.368+00 |
| description | vfs-zip: Virtual FileSystem abstractions for ZIP files |
| homepage | |
| repository | https://github.com/MaulingMonkey/vfs-zip.git |
| max_upload_size | |
| id | 283484 |
| size | 52,641 |
Currently this just bridges vfs and zip. Alternate VFS abstractions may be added in the future. Caveats:
vfs 0.4 lacks async interfaces, making it useless for browser targets.
zip isn't amenable to re-entrant access. This leads to Mutex spam, and forces open_file to copy/read the whole file up front.
| Feature | Description |
|---|---|
| default | |
| vfs04 | vfs = "0.4.x" interop |
| zip-deflate | "zip/deflate" (de)compression support |
| zip-bzip2 | "zip/bzip2" (de)compression support |
| (opt-in) | |
| zip-time | "zip/time" write timestamps when creating zip archives |
Crate uses #![forbid(unsafe_code)].
However, indirect dependencies do contain some unsafe - including, but perhaps not limited to:
| crate | version |
|---|---|
| bzip2 | 0.3.3 |
| crc32fast | 1.2.0 |
| flat2 | 1.0.14 |
| syn | 1.0.39 |
| time | 0.1.44 |
| winapi | 0.3.9 |
Currently 1.34.0...ish.
zip 0.5.6 has a MSRV of 1.34.0.
However, zip's MSRV policy allows 0.5.7 to bump this, and vfs-zip does not pin zip to this version.
vfs 0.4.0 has a MSRV of 1.32.0. However, it has no clear policy for when MSRV can be bumped.
Not all indirect dependencies have MSRV policies. For example, I've already pinned flate2 to "<1.0.16" since "1.0.16" broke 1.34.0 with "extern crate alloc;"
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.