7-Zip, drag and drop and the temp-dir mystery
Today I downloaded the Eclipse Ganymede M6 Java EE package. It is a 178MB ZIP archive containing the IDE. Downloading took a few minutes and then I was ready to go. Well, almost. Of course the ZIP needed to be extracted first. I use 7-Zip as the archive tool of choice. It has proven to be reliable and fast.
However it shares one "habit" I have seen so far with every archive tool I tried: Wherever you want to extract the contents of the archive, it will first put all files into the %temp% directory - often on the system partition - and only then copy the unpacked content to the final location.
With the Ganymede package this means 217MB of data in 4180 files and folders are first read from the archive and stored in a folder. On my P4@3GHz this takes about 110s. After that a copy of that some data - almost 4200 files - takes another 90s. Apart from that, instead of 217MB I now need twice as much almost half a gigabyte to store both the temp copy and the final one. Why is that necessary?
There are some threads on the 7-Zip forum also discussing this. Apparently (however I could not find it in the linked MSDN articles) this has to do with how Windows handles drag and drop. And indeed, extracting via the "two-folder mode" (F9 in 7-Zip, I did not know that before) puts the archive contents directly to the destination, saving almost half the time.
If anyone more knowledgeable in Windows development could shed some light on this, I would surely be grateful. For now, knowing the workaround is fine, too.
Just one more thing: When I first hit F9 in a 7-Zip window apparently nothing happened. Turns out the split control was all the way to the left, almost invisible next to the window border, so if you don't see a second pane come up, have a close look there :)
Comments
I stumbeled over this before in 7zip and winrar has the same nasty problem. Especially annoying if your C-partition is running out of space...
http://winscp.net/eng/docs/dragext
http://wiki.filezilla-project.org/FileZilla_FTP_Client#FileZilla_3.0.0-beta6_.282007-02-19.29
Great
7-Zip http://www.7-zip.org/ resolves the problem to the root with two panel view: the drop event is still in 7-Zip's control and the application knows were to put the data.
The obvious drawback is that from user's p.o.w. it is different than dropping the files around in another system's window, as it is usual for file move/copy.
PeaZip's http://peazip.sourceforge.net/ instead resolves the problem in another, interesting, way, querying the system for the handle of the active window under the mouse position, that allows to get the drop destination and also to emulate more naturally the user's drag and drop habits, but without using the insane Windows' drag and drop model!
Changing the folder settings in the plugin did not help.
THANKS for sharing.
So just always extract to the working folder, then tell Explorer to MOVE the file. That's how it works in every other program.