Index / tool

HatchZip

Category: Developer Tools
Rank: No. 1098Tools index
Pricing: Open Source
Type: TOOL
GitHub: 441 stars
Latest release: v0.1.2
Date: Published Oct 23, 2026

About

HatchZip extracts large archives in place by cutting each finished part off the end of the archive file, so the space it frees is reused for the next files. Extraction then needs roughly the size of the output rather than the output plus the archive. It reads ZIP, 7z, tar, tar.gz and split archives, checks that the extraction will fit before changing anything, and can resume after a crash.

What it does

A normal extractor leaves the archive and its contents on disk together until you delete the archive, so a 180 GB download that unpacks to 200 GB needs 380 GB. HatchZip consumes the archive as it works: it unpacks the last section first, writes and flushes those files, then shortens the archive file so the freed bytes go to the next section. It ships as a desktop app with a right-click menu, a command line tool, and a Rust library.

Why it's ranked here

It solves one concrete problem that WinRAR, 7-Zip and unzip do not touch: running out of disk while unpacking a big download. The safety design is specific rather than promised. Files are flushed to disk before any archive bytes are cut, every file's CRC-32 is checked, hostile paths and overlapping entries are refused before anything is deleted, and the documented crash tests kill the process at each risky step. It is dual licensed MIT or Apache 2.0 and makes no network calls.

What's good

The space check replays the whole run to find the moment of peak demand, not just the total, and changes nothing until the plan fits. Exit codes separate out of space, damaged archive and missing password, so scripts can react. An interrupted run resumes with the same command, and a restore command turns a half-eaten archive back into one any standard tool opens. A two gigabyte reserve of free space is kept by default. On filesystems that punch holes, a single large stored or deflated file frees archive space every 256 MiB as it extracts.

Tradeoffs

The archive is destroyed by design, so this is wrong when you want to keep it. A 7z made with 7-Zip's default settings can be one solid block, which frees nothing until it is all out; HatchZip refuses those when space is short. Hole punching on NTFS and APFS is marked unverified. RAR, xz and zstd compressed tar are not supported. Installers are not code-signed. Passwords are never stored, so a resumed encrypted run asks again. One giant file extracts at single-core speed.

How to use it well

Reach for it when a large ZIP, 7z or tar download will not fit next to its own contents, typically a game or dataset on a nearly full laptop drive or USB stick. Run the check command first; it reports the exact space needed and touches nothing. For downloads you cannot easily fetch again, use the verify-first option so every checksum passes before deletion begins. Leave the two progress files beside the archive until the run finishes. If you have room to spare, an ordinary extractor keeps the archive and costs nothing.

Technical notes+

Per docs/how-it-works.md, each format exposes truncatable units (a ZIP entry, a 7z solid block, a tar entry) processed in reverse order in batches of at most 512 units and 2 GB: decode in parallel to .hatchzip-part files, rename, flush (syncfs on Linux, F_FULLFSYNC on macOS), commit committed_len to an atomically replaced JSON journal, then ftruncate. The index tail is copied to a side file with its CRC-32 before any truncation, and storage::Reader serves it back so the zip, tar and sevenz-rust2 crates see the original archive. Streaming of 512 MiB-plus entries uses the zlib-rs C API (inflatePrime, inflateSetDictionary) to resume deflate at block boundaries recorded in bits, and the archive is never punched past the last durable resume point. A .tar.gz is one unit decoded front to back with punching behind the decoder. crates/core/src/archive/mod.rs sniffs format by magic bytes, rejects RAR, zstd, xz and bzip2 streams, and safe_path refuses .. components, drive letters and NUL bytes. crates/cli/src/cli.rs defines exit codes 1, 3, 4, 5 and 130 and reads passwords from a prompt, a flag or HATCHZIP_PASSWORD. install.sh verifies a SHA-256 checksum and installs under the user's home.

Observed

License: MIT OR Apache-2.0 (Cargo.toml workspace license; LICENSE-MIT and LICENSE-APACHE)
Language: Rust, edition 2024, Cargo workspace of core, cli, shell and gui crates (Cargo.toml)
Interfaces: Desktop app with right-click menu, command line tool (hatchzip, alias hz), and the hatchzip-core library crate
Supported formats: ZIP (including ZIP64 and self-extracting), 7z, uncompressed tar, .tar.gz/.tgz, and byte-split volumes of those (crates/cli/src/cli.rs)
Unsupported formats: RAR, .zst, .xz and .bz2 streams are refused (crates/core/src/archive/mod.rs)
Platform support: Windows 10 and 11 x64, macOS Apple Silicon and Intel, Linux via .deb, .rpm and AppImage (README.md)
Install surface: Installers, curl or PowerShell script with SHA-256 check and no root rights, cargo install, or build from source (install.sh, README.md)
Code signing: Windows and macOS builds are not code-signed (README.md)
Network access: None: no telemetry, accounts or update checks (SECURITY.md)
Hole punching verification: Verified on ext4 and tmpfs; NTFS and APFS compile but are unverified (docs/formats.md)

Read from README.md, Cargo.toml, LICENSE-MIT, LICENSE-APACHE, docs/how-it-works.md, docs/formats.md, crates/core/src/lib.rs, crates/core/src/archive/mod.rs, crates/cli/src/cli.rs, crates/cli/Cargo.toml, SECURITY.md, install.sh.

Tech Stack

Rust

Comments (0)

No comments yet

Editorially curated, with community endorsements as a secondary signal. Corrections welcome.