Not enough disk space to extract a ZIP, RAR or 7z: how to fix it

WinRAR, 7-Zip and unzip leave the archive on the disk until they finish, so the drive has to hold the archive and every extracted file at the same time: a 180 GB archive that unpacks to 200 GB takes 380 GB. Extract to another drive, free up space, or extract in place, which needs room for the extracted files only.

By Yash Bavadiya, maker of HatchZip. Updated .

Why does extracting need room for the archive and the files at once?

Because a normal extraction only copies data out of the archive. Nothing is deleted while it runs, and the archive stays until you delete it yourself.

The number to look at is the extracted size, not the size of the archive. Open the archive in WinRAR or 7-Zip and add up the Size column: that is what the extraction writes. The Packed or Packed Size column is what the archive already takes. Video, music and most game data barely compress, so the two are often close, and the drive then needs almost twice the archive's size in total.

What does the error look like?

Each program words it differently, but they all mean that a write failed because the drive was full:

  • Windows: "There is not enough space on the disk." This is the system's text for error 112, as Microsoft lists it, and programs that pass on the Windows error show it.
  • WinRAR: "Not enough disk space for" followed by a file name, or "Write error in the file". Both are messages in WinRAR 7.13.
  • unzip on Linux and macOS: "write error (disk full?)".
  • 7-Zip on Linux: "No space left on device".

If the drive you are extracting to clearly has room, the full drive is a different one, or the drive refuses a large file. Those cases have their own guides: WinRAR says not enough space on disk when there is and 7-Zip says there is not enough space on the disk.

Can I extract to a different drive?

Yes, and it is the simplest fix when another drive, such as a second internal disk or a USB disk, has room for the extracted files. The archive stays where it is; only the destination needs the space.

  • WinRAR: open the archive, choose Extract To, and pick a folder on the other drive.
  • 7-Zip: open the archive, choose Extract, and change "Extract to".
  • Windows, for a ZIP: right-click it, choose Extract All, then Browse.

It works the other way round too. Move the archive onto a USB disk first, then extract it from there to the internal drive, which then only needs room for the files.

Before you start, check how the USB disk is formatted: in Explorer, right-click it, choose Properties, and read File system. FAT32 cannot hold any single file of 4 GiB or more, according to Microsoft; exFAT and NTFS have no such limit.

How do I free up space on Windows?

Use Storage Sense (Settings, System, Storage) or the older Disk Cleanup tool. Both remove temporary files and other files Windows can do without; Microsoft's guide to freeing drive space explains each one.

Look in your Downloads folder as well, for archives you already extracted and installers you already ran. Freeing space solves the problem only if you can free as much as the extracted size. The next two fixes need much less.

Can I delete the parts of a split archive while it extracts?

Sometimes, by hand. If the archive comes in parts, such as game.part1.rar, game.part2.rar or game.7z.001, game.7z.002, the extractor reads them in order, and once it has moved on to the next part, the finished one is no longer needed. Deleting it gives its space back.

This is fiddly and has two risks. You have to know which part the extractor is reading, and a part deleted too early is gone. If the extraction then fails, for example on a damaged part, you cannot start over without downloading the deleted parts again. Only do it with a download you can fetch again.

HatchZip does this step itself: it deletes each volume of a split 7z, ZIP or RAR once nothing in it is still needed. In the test published in its README on 2026-10-22, a 7z split into 5 volumes of 40 MB extracted 200 MB of files with at most 210 MB of the disk in use.

Can I extract without needing space for the archive as well?

Yes, by extracting in place. HatchZip extracts the archive from its last file to its first and, once each batch of files is safely written, cuts that part off the end of the archive file. The freed space holds the next batch, so the drive needs room for the extracted files plus a margin, and when it finishes, only the files are left.

It reads ZIP, 7z, tar, .tar.gz, RAR and split archives, runs on Windows, macOS and Linux, and is free and open source. Download HatchZip.

The trade-off is that the archive is used up. If you need to keep it, a normal extraction is the right tool, and it needs the full space.

How can I check whether it will fit before I start?

Run hatchzip check on the archive. It reads the archive's index and the drive's free space, changes nothing, and prints both what a normal extraction needs and what extracting in place needs. This is the archive from the test below, on a drive with 50.6 MB free:

$ hatchzip check game.zip --keep-free 5M
game.zip  180.1 MB zip, 200.0 MB uncompressed in 22 entries
  available                    50.6 MB
  standard extraction needs    200.1 MB
  required                     28.6 MB (+5.0 MB reserved)
  available after              30.6 MB
  • "standard extraction needs" is what WinRAR, 7-Zip or unzip would need here: 200.1 MB, about four times the free space.
  • "required" is the most free space HatchZip needs at any moment of the run, and "available after" is what is left when it finishes.
  • When it does not fit, check says how much more space is needed and exits with code 3. The desktop app shows the same figures before you choose Extract.

By default HatchZip keeps 2 GB free, so the drive never fills completely. The test disk was only 220 MiB in total, so the reserve was lowered to 5 MB with --keep-free 5M.

Measured: unzip, 7-Zip and HatchZip on a nearly full disk

Checked 2026-10-25. Method: 200.0 MB of data in 21 files, mostly random bytes so that it barely compresses, was packed into a 180.1 MB ZIP with Info-ZIP Zip 3.0 and into two 180.0 MB 7z archives with 7-Zip 25.01, one with -ms=20m (several solid blocks) and one with default settings. Each archive was copied alone onto an empty 220 MiB disk, which left 50.6 MB free, and extracted onto the same disk.

ToolArchiveResult
unzip 6.00ZIPStopped while writing file 6 of 21: "write error (disk full?)"
7-Zip 25.01Both 7z archivesStopped while writing file 6 of 21: "No space left on device"
HatchZip 0.1.3ZIPFinished: 21 of 21 files, each byte-identical to the original
HatchZip 0.1.37z, -ms=20mFinished: 21 of 21 files, each byte-identical to the original
HatchZip 0.1.37z, default settingsRefused before changing anything: the archive is one solid block, which needs 200.1 MB free

Fedora 43 (Linux 6.19), Intel Core i7-14700HX. The 220 MiB disk was a tmpfs, a disk held in memory, standing in for a full laptop drive. HatchZip ran with --keep-free 5M, as explained above. The ZIP results match those first published in the HatchZip README on 2026-10-21.

Where HatchZip fits, and where it doesn't

It fits when the archive and the files are on the same drive, and the drive has room for the files but not for both. It also takes over the job of deleting split parts by hand.

It does not help when:

  • The drive cannot hold the extracted files themselves. Only another or a bigger drive helps then.
  • The archive is a 7z made with 7-Zip's default settings. That can be one solid block, which HatchZip can only free once all of it is out, so it needs about as much space as a normal extraction. hatchzip check tells you first, as in the test above.
  • The archive is a solid RAR. HatchZip extracts it only while keeping the archive, which needs the full space.
  • The cause is WinRAR's or 7-Zip's temporary folder, or a FAT32 drive refusing a file of 4 GiB or more. Those are not a lack of space on your drive; see the WinRAR and 7-Zip guides.
  • You want to keep the archive afterwards.
  • The archive is a .tar.xz or .tar.zst, which it does not read yet.

The archive is used up as the files come out. If the download is damaged, the files before the damage come out and the archive is partly gone; --verify-first reads the whole archive before deleting anything, for downloads you cannot fetch again.