Unpacking more than the disk holds

Unpacking an archive normally needs room for the archive and everything inside it at once. On a disk that is nearly full, that means the extraction fails halfway.

HatchZip takes a different route. Files can always be shortened from the end, on every operating system and filesystem, so it works from the end of the archive and truncates it behind itself once the files in a unit are safely on disk. A .tar.gz can only be decoded from the front, so it can't be cut that way. For that case it punches holes in the archive behind the decoder, which frees the space without changing the file's length.

The docs include a measurement. A 385.9 MB .tar.gz made by GNU tar 1.35 and gzip 1.13 holds 501.1 MB in 2,016 entries. The disk had 473.9 MB free. GNU tar -xzf ran out of space. HatchZip finished in 1.0 s, its lowest free space was 111.8 MB, and every file's SHA-256 matched.

The catch is in the project's own coding rules: the tool destroys its input. Its invariant is that the journal never claims a file before it is durable, and the archive is never truncated past an entry the journal doesn't claim. There is also a --keep-archive option for people who want the archive left alone.

Two more limits from the docs. Without hole punching (FAT32, exFAT) nothing is freed until the end. And a 7z that 7-Zip wrote as one solid block frees nothing until all of it is out, so there is little to gain there.

The numbers come from the project's own docs, measured on a tmpfs, not from an independent test.