HatchZip extracts archives from the end and cuts off each finished part, so a 180 GB game unpacks on a nearly full disk

Every extractor has the same dumb math. A 180 GB game download that unpacks to 200 GB needs 380 GB free with WinRAR, 7-Zip or unzip, because the archive and everything pulled out of it have to sit on the disk at the same time. The HatchZip site puts its number right under that one: a little over 200 GB.

The trick works because of how archives are laid out. ZIP and tar store files one after another, 7z stores solid blocks, and ZIP and 7z keep their index at the very end. HatchZip copies that index to a side file, extracts the last piece in the archive, flushes it to disk, renames it into place, and only then truncates the archive to where that piece began. Then it does the next-to-last piece. It’s like eating a sandwich from the far end so you never need a second plate. Split archives get the same treatment with whole volumes deleted one at a time, and RAR, stored file after file like tar, frees a volume once every file reaching into it is out.

The README is blunt about the risk: “HatchZip destroys the archive as it extracts.” So most of the engineering goes into never losing a file mid-cut. Each file is written, flushed to the physical disk and renamed before the archive bytes holding it are cut, so a crash leaves either the file or its bytes in the archive. Press Ctrl+C and it finishes what it’s writing, saves progress and exits. A crash, a power cut or a disk filled by something else resumes the same way: run the command again. And hatchzip restore turns what’s left back into a normal archive holding exactly the entries not yet extracted, which 7-Zip, WinRAR, unzip or tar open as usual.

The repo’s own test is 200 MB of game data in 21 files, on a 220 MiB disk with about 50 MB free. unzip ran out of space at file 6 of 21. HatchZip finished a ZIP, a 7z with ten solid blocks and a five-volume split 7z, every file byte-identical. Then the honest row: a 7z made with 7-Zip’s default settings is one solid block, and that block can’t be freed until all of it is out, so HatchZip refused it before touching anything. With room for the whole block it works. On that disk there wasn’t.

Other edges are listed plainly. A .tar.gz can only be decoded from the front, so HatchZip extracts it front to back and punches holes in the compressed bytes it’s used, on filesystems that can. .tar.zst and .tar.xz are refused for now. Solid RAR only extracts with the archive kept. RAR support is in the release builds but not in a plain cargo install. It has no networking code at all, and CI fails if a networking crate enters the dependency tree.

The binaries aren’t code-signed yet, so Windows shows “Windows protected your PC,” and the README says the v0.1.3 Windows setup trips 4 of 70 engines on VirusTotal, all heuristic scores, with Microsoft Defender calling it clean. It also warns that hatchzip.com is not the project. The real downloads come from the GitHub releases and hatchzip.dev, and from 0.1.3 on each release file carries signed build provenance you can check with gh attestation verify.

Code signing is planned. When, the README doesn’t say.

Disk space has always been the hidden cost of a big download. Game installs keep growing, and the people with the least free space tend to be the ones on the cheapest laptops, where a 512 GB drive is already half full of the operating system and last year’s game. An extractor that needs only the output size quietly moves the line on what fits.

The bigger lesson is in how HatchZip handles risk. A tool that deletes your data on purpose earns trust by refusing loudly: it checks the fit before it changes anything, keeps a safety margin the whole way, and says no to the one solid block it can’t free safely instead of guessing. That’s like a surgeon who won’t start until the blood bank confirms your type.