I unzipped a 124 GB file with 25 GB of free space

I had a 124 GB zip that unpacks to 128.6 GB. 7-Zip, WinRAR and Explorer all need space for the zip and the files at the same time, so that's about 253 GB for one archive.

But you only need the zip while the files are coming out. So I wanted to know if you can delete the zip piece by piece while you extract it.

You can. A zip keeps its file list at the end, so you can work backwards. Write out the last file, flush it to disk, note in a small journal that it's done, then cut that file's bytes off the end of the zip. The drive gets the space back and the next file uses it. The zip shrinks while the folder grows.

If the power goes out at any point, either the file is already on disk or its bytes are still in the zip. You never lose both, and the journal says where to continue.

The extractor doing this is hatchzip, a small open source CLI. I added it to Devpit, a terminal app I'm building for Windows dev machines. It now has an "Extract big archive in place" screen under Clean that checks the space first, asks before it starts, shows progress, and can pause and resume.

How much space it needs

Not zero. Roughly the difference between the unpacked size and the zip size, plus your biggest single file, plus 2 GB kept free. For my archive that was about 13 GB instead of 128.

If the archive is one huge file you need room for that file, there's no way around it.

The test

My drive had 182 GB free, which is enough for a normal extract. So I filled it up with a dummy file first:

fsutil file createnew E:\filler.bin 157700000000 

That left 25 GB free. Then I ran the extract from Devpit. The zip went 123.9, 101.7, 66.1, 31.4, 14.4 GB, then it was gone. Free space never went below about 13.7 GB. It took 6 minutes 55 seconds and all 299 entries came out.

If there's lots of free space it doesn't cut the zip as it goes. It extracts normally and deletes the zip at the end. It only does the in-place thing when it has to.

Then I crashed it

Second archive, 77 GB, with 10 GB free. Before I could crash it, it stopped on its own at 20% saying the disk was full when it wasn't. On NTFS, space from a truncated file isn't given back until the program closes the file. With 10 GB of room it hit that wall every 20 to 40 seconds. A restart fixes it, so Devpit now retries by itself as long as each try makes progress. I haven't re-run this test on a real archive since that change.

Then I resumed and killed Devpit from Task Manager at 26%. When I opened it again, the Clean menu said there was 1 unfinished extraction. I picked Resume and it finished. I checked the folder against the file list I saved before starting: 1,944 of 1,944 files, all sizes matching.

When it won't work

One huge file. Solid 7z or RAR archives, which Devpit refuses up front. Extracting to a different drive. Network drives.

It also deletes your archive, which is the whole idea. Keep a copy if it's your only one. The confirm button defaults to No.

Try it

scoop bucket add zubyr https://github.com/zubairbinshaukat/scoop-bucket scoop install devpit 

Then go to Free Up Disk Space and pick Extract big archive in place. It installs the extractor if you don't have it.

If you try it on something big, let me know how it went, especially if it breaks.