Crates.io | vfs-zip |
lib.rs | vfs-zip |
version | 0.2.1 |
source | src |
created_at | 2020-09-01 17:38:54.7567 |
updated_at | 2020-09-09 00:24:32.368 |
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.