Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

What is the reason for 7-zip / WinRAR to first unzip files to "temp" and then move them to 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!).


Edit:

Please explain why they are not done in place.

share|improve this question
3  
If you specify `` as the temporary folder in WinRAR, it should extract directly to the destination. –  user193985 Jan 30 '13 at 12:59

4 Answers 4

up vote 44 down vote accepted

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.

share|improve this answer
5  
Absolutely brilliant -- thanks for this! This has boggled me for years, but I've never taken the time to track down the "what" and why". The odd times I find my C: temp folder filled to the whazoo, I trudge through Winrar's options to find where it must be set to first extract to a temp folder on C:. But alas, I don't find it. I never connected the correlation between the two methods, and now appreciate seeing the light :) Thanks! –  Coldblackice Nov 18 '12 at 23:10
1  
One thing wrong here is that Explorer does not move the file but rather copies it. Which is really irritating because moving is really fast (except when moving from partition to partition) and should have been the ideal choice (it doesn't waste space), but the idiots at Microsoft thought it's a great idea to copy from the temporary folder then just leave the temporary folder data lying around. Not only is the extraction of a huge archive going to take double the space, it's also going to take almost twice as long! –  ADTC Apr 1 at 3:45
    
They probably had a good reason for that, and it may have been due to some kind of limitation of systems and/or DDE on which it was based, when they first designed OLE, back in the days of Windows 3; a limitation which may or may not apply today. –  Synetech Apr 2 at 0:51

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.

share|improve this answer
    
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 Aug 27 '11 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 Aug 27 '11 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 Aug 27 '11 at 1:08
    
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 Aug 27 '11 at 1:12

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.

share|improve this answer
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 Jun 25 '11 at 15:23
3  
Edited to better reflect your question –  A Dwarf Jun 25 '11 at 15:29
    
A wired thing is that even the moving is from C:\%system dir%\temp to C:\some where, it is still as slow as cross region moving.... –  user69835 Jun 25 '11 at 15:39
4  
@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. –  Dour High Arch Jun 25 '11 at 15:56
2  
Re "the operating system will dispose of the temporary file when it sees appropriate": Does Windows ever do that? –  grawity Jun 25 '11 at 16:17

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?

share|improve this answer
    
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 Jun 25 '11 at 15:22
    
2nd paragraph: extract to "temp" does not prevent anything if the zipped file is already corrupted. –  user69835 Jun 25 '11 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 Jun 25 '11 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 Aug 27 '11 at 0:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.