xevrion/hatchzip

The problem

Extracting a big archive normally requires free space for both the archive and its contents at the same time: a 180 GB download that unpacks to 200 GB needs roughly 380 GB free, which fails on laptops, Steam Decks and small VPS disks. HatchZip avoids that by reading the archive from its end and cutting away bytes it has already turned into files, so the archive itself shrinks while the output grows.

What's different

Ordinary extractors (unzip, 7-Zip, WinRAR) treat the source archive as read-only and extract files one by one into new space; they need the full doubled footprint. HatchZip's approach is destructive by design and reuses the archive's own blocks for the output. It adds three things beyond that core trick: a check command that computes exactly how much space is needed before touching anything, crash safety so an interrupted run resumes rather than corrupting output, and awareness of solid 7z blocks, refusing loudly when a block cannot be freed until all of it is out. The trade-off is that the archive is gone afterwards unless you opt out, and solid archives may still need significant headroom.

Who it's for

People who unpack large game downloads, datasets or backups on disks that are nearly full: Steam Deck and laptop users, homelab and VPS operators with small volumes, anyone who currently deletes something to make room. It is not for you if you must keep the original archive (use "keep archive" mode or a normal tool), if your archives are solid 7z with few blocks and little free space, or if you need signed installers in a managed Windows/macOS fleet. Users who want a stable, audited archive library rather than a CLI/GUI should look at the mature 7-Zip or libarchive ecosystems.

Cost of adoption

Binaries are published for Windows, macOS and Linux, plus Homebrew, Scoop, AUR and crates.io (cargo install hatchzip); RAR support is a feature flag that compiles UnRAR's C++ code under its own license. The engine also ships as the hatchzip-core library. Risks: the Windows and macOS builds are not code-signed, so users must bypass SmartScreen or Gatekeeper; the project is days old with a single maintainer and no long-term track record; crash recovery and hole-punching benefits depend on the filesystem (ext4/XFS/btrfs verified, NTFS/APFS claimed but not verified). The space savings are format- and layout-dependent, and the README itself documents the solid-block refusal case.

Verdict

The idea is genuinely useful and narrowly correct: extracting in place is the right answer to a real, common disk-space failure. Momentum is high but young — 1,644 stars in about three days and a #6 new-board position are a spike, not a track record, and the tiny Hacker News thread suggests curiosity more than adoption. The engineering signals in the README (byte-identical output comparisons, crash tests, signed build provenance) are better than most three-day-old projects, but a destructive-by-default tool deserves skepticism until independent users have run it on their own archives. Worth a check on a scratch disk today; wait for a few release cycles before trusting it with the only copy of your data.