A little more on Windows Drag and Drop

A few days ago I complained about the silly drag and drop behavior of several ZIP tools, my favorite 7-Zip included. My post contained a remark that this is actually a Windows problem, but I did not have any further information on it other than a few links to the 7-Zip forum where people talked about this.

Thanks to an anonymous commenter on the earlier post I can now point to a good source of more information: The also fabulous WinSCP tool comes with a special drag and drop extension that works around the limitation of first unpacking to a temp file and then copying to the final destination, making unzip operations very slow. From the documentation page at http://winscp.net/eng/docs/dragext you can learn this:

Here is short explanation: Windows drag&drop mechanics does not allow source application of drag&drop operation to find out easily, where the files are dropped. It is up to target application (Windows Explorer usually) to transfer files to destination. It is rather reasonable, because source application can hardly transfer files to all possible destinations. [...]

To allow direct drag&drop downloads, the shell extension was developed. It misuses Windows Explorer CopyHook’s. CopyHook is COM object (DLL library) that is called by Windows Explorer whenever directory (not file) is transferred within file system. When you drag anything from WinSCP, it creates empty dummy folder in temporary directory and pretends that you as user drag that directory. Once your drop it to Windows Explorer, it calls the CopyHook’s (including the WinSCP shell extension), telling it what and where was dragged. This way WinSCP knows the actual destination. It cancels the drag&drop operation, so the dummy directory is not copied by Windows Explorer and transfers your actual selection to now-known destination.

Go read the whole text in case you'd like to know the full story. Unfortunately the link to the MSDN library seems dead, so here is a (currently working) replacement: http://msdn.microsoft.com/en-us/library/bb776048(VS.85).aspx

BTW, why do they keep changing their URLs all the time? Even most private blogs jump through hoops to keep their permalinks valid when they change the site, why can't MS?

This is definitely a reason for me to use the installer package in the future instead of the standalone executable download I used to grab.

Vista still stands in its own way with USB drives

Some things will apparently never change. After I learned that the notorious temp-dir-copy-cycle most zip tools go through is probably a Windows feature, today I came across an issue I thought should finally have been addressed in "Windows 6" (Vista).

I had inserted a USB pen drive ("USB DISK") earlier and just wanted to eject it.

From my point of view this is a fairly typical scenario. When you insert the drive Windows will offer to open it in an explorer window. This is just what I did. I copied a file from there to the desktop and wanted to remove the device:

"Auswerfen" is the German word for "Eject". Guess what...

The same old story once again... This lengthy message tells me that some application is using the drive and that removing it might cause data-loss, kittens could die and the whole blah blah.

Of course I can click on "Fortsetzen" (Proceed), but this is not what I would expect of a 21st century user interface... The least thing would be a list of process names to get any clue of what program might still be accessing the drive and whether it is okay to close their handles or not...

Why on earth is it so difficult to just detect that no one else but the very same explorer window that offered me the context menu has a handle on that drive? Maybe I would even accept the warning if the pen drive's content was showing in a second window, but come on, how difficult can it be?

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 :)