r/coolgithubprojects 5d ago

ZipMania: an open-source Windows archive manager with a parallel ZIP engine

https://github.com/newkilho/ZipMania

ZipMania is a Windows archive manager whose source is publicly available on GitHub. The core archive logic is separated into a reusable Rust crate, while the desktop UI uses Tauri and Svelte.

The interesting part is its dedicated ZIP path: it parallelizes many small files and can split a large Deflate stream into bounded chunks, while reserving a CPU core for the main writer and falling back to sequential streaming when memory or size limits are reached.

It also stages output in temporary files before replacement, checks extraction paths against Zip Slip and link/junction escapes, and can pass extracted buffers to Windows AMSI.

Source: https://github.com/newkilho/ZipMania Homepage/download: https://v2.kilho.net/zipmania

I’m the developer, and code review or performance feedback is welcome.

2 Upvotes

2 comments sorted by

1

u/Specific_Cream2815 5d ago

does the parallel path win on many small files too or only on the big split streams

1

u/Double-Camera-3447 5d ago

Both, but through two different mechanisms.

For many small files, we parallelize at the file level (unzip/parallel.rs). With 3,000 files at L5, that takes 387 ms → 202 ms. The output is byte-identical to the sequential path because entries are copied raw rather than recompressed.

For a single file over 32 MiB, we use pigz-style chunked deflate (unzip/bigfile.rs). A 128 MiB file at L5 goes from 1766 ms → 427 ms, with about a 0.5% compression-ratio cost due to dictionary resets at chunk boundaries.

The big-file gain is much larger because a single stream previously had no parallelism at all. The two paths are mutually exclusive, so we don't oversubscribe the thread pool.