Menu

The other day, I needed to extract a 7 GB zip file containing a VMware virtual machine onto the hard drive of a nearly stock 64-bit Windows 7 Professional machine. Because this machine did not have a third-party compression utility installed, I tried to extract it using Windows’ native zip utility, called Compressed Folders.

This failed with a pretty neat error.

You need an additional 5.99 PB to copy these files.

As you can see in the screenshot above, Windows reported that…

Copy Folder

There is not enough space on Local Disk. You need an additional 5.99 PB to copy these files.

Local Disk
Space free: 125 GB
Total size: 232 GB

[Try Again] [Cancel]

I found the 5.99 petabyte requirement pretty amusing, but I was in a hurry, so I downloaded the excellent 7-Zip, unpacked the file, and set about building the vm.

I had meant to write a post about the error message, but some time passed and I forgot all about it. Then, about three weeks later, someone else in the department tried to extract a copy of the file on a 32-bit Windows XP Professional machine and got the same error. At that point, I had to investigate.

The Compressed Folders native Windows utility seemed to be unable to accurately calculate the free space needed to extract the file. The file was admittedly pretty large, but was size the only reason?

According to various threads, the popular theory is that the problem stems from size limitations on compressed files. Windows Vista and later have a 4 GB limit (compressed and uncompressed size), while XP has a 2 GB limit.

Strangely, the same error appears before a copy process when the OS encounters a file that exceeds its maximum individual file size, which I can understand, but find a bit confusing in the context of a zip file. Certainly, both Windows 7 and XP (NTFS) were able to handle the file to begin with, and only had a problem when decompressing it.

My best guess is that the file was created using the Compressed Folders feature on XP. The file exceeded the maximum size limit for that version of Windows, but due to the bug described in MS KB article 301325, the file was created anyway using 32-bit headers. When the file was later opened by Compressed Folders, the 64-bit headers were read (as a file of that size would naturally use 64-bit headers), but that information was garbage, preventing Windows from accurately calculating the space required to extract.

If anyone has a more complete understanding of the cause of this error, please leave me a comment.

I had the same problem with a 10GB zip file produced on Cent OS (Zip 3.0): Windows 7 asked for 9PB free, but Win-RAR could decompress the file. I solved the problem by using the “-X” zip option, which is “Do not save extra file attributes (Extended Attributes on OS/2, uid/gid and file times on Unix)”. Apparently, Windows 7 tries to translate Unix information and gets wrong files sizes.