Why do 7-zip / WinRAR unzip files to "temp" before moving them to their destination?

I do not see any advantage against just directly unzipping to destination. It is really irritating, especially for large files (as it is now!).


Please explain why they are not done in place.

  • 3
    If you specify `` as the temporary folder in WinRAR, it should extract directly to the destination.
    – user193985
    Commented Jan 30, 2013 at 12:59

4 Answers 4


How exactly are you extracting the files? Are you using the command-line or the GUI? Are you dragging the files or selecting them and using the extract function? Are you using the shell-extension context-menu?

If you enter a destination folder and then select the extract function or use the shell-extension, then they do not extract to a temporary folder first, they extract directly to the destination.

If you select the files in the UI and drag them to the target folder, then it will extract to a temporary folder.

The reason is in how the destination is selected. If you enter the target folder or use the context-menu item, then the program knows exactly where it needs to extract to. However, if you merely drag the files, then due to how the drag-and-drop function of OLE works, the program does not know where the target folder is. In other words, it is Explorer that receives the target folder, not the archiving program. As a result, the program cannot know where to extract them, and so simply extracts them to the temp folder, then Explorer moves them once it’s done. You can see this clearly by extracting a large file using both methods. When you drag it out to a folder, it extracts, then you see Explorer’s standard file operation dialog moving it to the folder. If you specify the folder and click Extract, it extracts and no further processing is done.

Feel free to peruse the source-code for 7-Zip to see how extraction location is handled.

I learned this the hard way several years ago when I wanted to implement drag-and-drop in a program I was writing.


It is done so memory requirements for decompression are kept to a minimum.

If they didn't use the filesystem, decompression would happen in memory. Under low memory conditions, or for large compressed files this would sooner or later exhaust available memory and start the process of memory paging.

Paging under these circumstances would be a lot slower than just using the filesystem because the file is still being decompressed (and page files keep being added), but also because as the file is being decompressed, it is being checked for errors and there's as such a lot of read/write operations. The worst thing that can happen to a page file.

EDIT: Regarding the use of a temporary directory, this is so to follow many operating system guidelines. If the decompression fails, there's no guarantee the program performing the operation cleans up after itself. It may have crashed for instance. As such, no residual file remains in your target directory and the operating system will dispose of the temporary file when it sees appropriate.

  • 3
    While true, that doesn't explain why the files are compressed to a temporary directory first and then moved to the destination one. The operation could also be taking place right there.
    – slhck
    Commented Jun 25, 2011 at 15:23
  • 3
    Edited to better reflect your question
    – A Dwarf
    Commented Jun 25, 2011 at 15:29
  • 5
    @Dante, that is not true. Moving a file on the same partition simply changes the index of the file in the file system to the new directory, it does not copy any data and takes only an instant. Don't believe me? Try it, cut a multi-GB file from one folder and paste it to another folder; it takes less than a second. They try the same thing to another drive or partition. Takes minutes. Commented Jun 25, 2011 at 15:56
  • 5
    Re "the operating system will dispose of the temporary file when it sees appropriate": Does Windows ever do that? Commented Jun 25, 2011 at 16:17
  • 2
    This completely false answer should be removed. 7zip only decompresses to a temp folder during drag-and-drop operations and this is due to limitations of Windows. See superuser.com/questions/197961/… for more info.
    – dss539
    Commented Jun 5, 2017 at 21:17

The reason is simpler than you think: Many programs unpack files to %temp%, is that the destination filesystem might not have enough space.

Now, you might know that your filesystem might have enough space, however the application does not. What if that filesystem is in use by the OS or another application and gets filled up while decompressing?

Developers make the assumption that %temp% has "unlimited" space, while your destination does not.

  • 1
    Not quite; that’s not a reason to use the temp directory. The application does (or at least can) know whether there is enough space or not. First, the archiver knows exactly how big the compressed files are when they are decompressed and can allocated them beforehand, and then fill them in as it decompresses, and second, it is quite simple to query the free space on a drive. Besides, if there is not enough space, then it just decompresses while it can, then throws an error when it runs out of space.
    – Synetech
    Commented Aug 27, 2011 at 0:36
  • Actually, this is quite the answer. Just because an application can preallocate the space on the target destination, does not mean it will have exclusive access to it. The application can query the destination and see if it has enough space, but while that query is happening, before its able to allocate space, another application can take some of that space.
    – Keltari
    Commented Aug 27, 2011 at 1:05
  • On top of that, a users temp space is tied to that user at the filesystem level. If there was a crash or another failure, another user could not see the temp files. The destination might not have such security restrictions, so its safer not to have possibly sensitive data hanging out on another filesystem.
    – Keltari
    Commented Aug 27, 2011 at 1:08
  • 1
    Like I said, if it runs out while decompressing, it simply gives an error message. How would extracting to a temp drive fix it? If there isn’t enough space, then there isn’t enough space after the files are extracted to the temp drive, and it wastes all those CPU cycles and drive reads/writes extracting to the temp drive for nothing. Like I said in my answer, feel free to peruse the source-code for 7-Zip, or contact Alexander Roshal to ask him about WinRAR. Besides, like I also said, if you specify the target or use the context-menu, it does not use %temp%.
    – Synetech
    Commented Aug 27, 2011 at 1:12

Not being a 7-zip or WinRAR developer, my comments here are purely speculation. That being said, using temp space to unpack to until everything is complete help to verify that all of the files are intact (i.e. that the zip is not corrupted).

There is nothing worse than unpacking a large compressed file, having started working on files at the beginning of the archive; only to find out that something is corrupted at the end of the archive. At that point you lose confidence in everything.

My last comment is that I don't recall seeing this behavior from 7-zip. When I right click and say extract here, I generally have access to the files as they are being unpacked. Have you double checked that it isn't a setting somewhere?

  • 3rd paragraph: I cannot find such settings, and it is a large bunch of files (4G) I was extracting just now, I am pretty sure all 4G was moved slowly at last.
    – user69835
    Commented Jun 25, 2011 at 15:22
  • 2nd paragraph: extract to "temp" does not prevent anything if the zipped file is already corrupted.
    – user69835
    Commented Jun 25, 2011 at 15:24
  • It prevents you from seeing files out of a corrupted zip. The logic is that you don't get to see anything until everything is verified. As far as the setting goes, I'm not sure what to tell you. If I tell 7-zip to extract a large tar file to my Desktop, I start seeing the files immediately. It could be because tar is not a compressed format.
    – Kirk
    Commented Jun 25, 2011 at 15:28
  • > The logic is that you don't get to see anything until everything is verified. That’s absurd. How then would you recover some files from a corrupt archive? The reason you don’t experience it is because you used the shell-extension instead of dragging the files from the GUI.
    – Synetech
    Commented Aug 27, 2011 at 0:47

You must log in to answer this question.