When dragging files out of an archive to a certain destination, 7-zip extracts those files to the temp directory of the user and then let the files move by the explorer to the destination. This is a rather bad behaviour, because there are at least 2 problems:
• the drive with the temp directoy may be low on disk space or simply to low for a big file
• when using SuperCopier: SC intercepts the move command, but sometimes the files already got deleted from the temp directory (for whatever reason?) and there is notghing for SC to move anymore
The best solution would be, if 7-zip extracts the files *directly* to the destination, when dragging & dropping. In the range of freeware archive tools, I only know Peazip which does this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WinRAR have same behaviour. I think program simply don't know where it drops files, for example you can drop them into another archive in another program.
Also I has interesting experience with WinRAR — it failes to unpack files to administrator's folder from user account in Vista, but with drop into Explorer it works — Explorer asks for permission.
So if you want to extract directly — don't use drag-and-drop.
Usually temporary files got deleted when you close application or it thinks that them not needed anymore.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The application itself is the one doing the extraction, and it always knows what the drop target is. It doesn't necessarily have to care, which is probably the case with most apps; it's certainly simpler to always do one thing that works whether you're dropping to a folder or another application. With a little more effort it'd be possible to have direct extraction though; I might look into a patch for that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would be great, thx :). Most of the time I either use "Extract here" or I drag & drop the files where I want to, I find that much more convenient.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
afaik this behaviour only occurs if you d'n'd from 7-zip to explorer. If you d'n'd inside 7zFM (two-panels-view) it extracts directly.
So if I'm right you would have to patch windows... ;-)
Best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this happens when you drag'n'drop from 7-zip to explorer. But why is this a problem of windows? WinZip, WinRar, PeaZip all extract to the destination directly, instead of extracting to the Temp Directory and then tell the Explorer to move the files from there to the destination..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least my WinRar do extracting to temp directory and then tell the Explorer to move the files from there to the destination. Just tested that. Don't know who failed with design though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for what I know this problem is common to all programs using standard Windows' drag and drop model, like 7-Zip and WinRar (I've not tested latest WinZip releases).
On PeaZip I have to use a custom drag and drop mechanism written ground up to work around this Windows' limitation; it basically catches the Explorer's windows path and send data there as a normal extraction/copy/move operation.
The tradeoff is that PeaZip can only drop data in opened folders (or desktop), not on icons or other applications, and don't shows Windows' drag and drop mouse pointers during the operation.
However IMHO the tradeoff is reasonable for this type of applications (that may deal with large amount of data, or sensitive encrypted information) since it allows to avoid writing data to unwanted location (secure deletion is not fast), does not temporarily need a double amount of free disk space and don't need to write the data two times.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMHO the right way to solve this problem is to create virtual file system and present it as source for files. There is SDK for such task — http://www.pismotechnic.com/pfm/ But you will face perfomance problem if files will be accessed in non-linear form.
I'm wonder how drag-and-drop really works (never dig there), for example you can drop file to Word document and it will be saved in it — is it also working through temporary file? Another way to do this is through clipboard — you copy file to clipboard and paste in Word. (I pressed properties on embedded object and window says that it is located in temp folder) Also you can paste from clipboard in different formats — content can be created on paste operation, not on copy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why copy? It would be less of an issue if the files extracted to a TMP directory and were then moved to the destination.
No big deal, but maybee the program should default to the two-pane view that provides much better performance?
Maybe even a warning for big files in drag-n-drop mode?
Example: You have choosen to extract the 10GB folder "MYVIDS" to "c:\documents and settings\Administrator\desktop" the drive "C:\" only has 19.9 GB of free space, please extract using the two-pane view of 7-Zip File manager.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When dragging files out of an archive to a certain destination, 7-zip extracts those files to the temp directory of the user and then let the files move by the explorer to the destination. This is a rather bad behaviour, because there are at least 2 problems:
• the drive with the temp directoy may be low on disk space or simply to low for a big file
• when using SuperCopier: SC intercepts the move command, but sometimes the files already got deleted from the temp directory (for whatever reason?) and there is notghing for SC to move anymore
The best solution would be, if 7-zip extracts the files *directly* to the destination, when dragging & dropping. In the range of freeware archive tools, I only know Peazip which does this.
It drag-and-drop mechanism's problem.
WinRAR have same behaviour. I think program simply don't know where it drops files, for example you can drop them into another archive in another program.
Also I has interesting experience with WinRAR — it failes to unpack files to administrator's folder from user account in Vista, but with drop into Explorer it works — Explorer asks for permission.
So if you want to extract directly — don't use drag-and-drop.
Usually temporary files got deleted when you close application or it thinks that them not needed anymore.
The application itself is the one doing the extraction, and it always knows what the drop target is. It doesn't necessarily have to care, which is probably the case with most apps; it's certainly simpler to always do one thing that works whether you're dropping to a folder or another application. With a little more effort it'd be possible to have direct extraction though; I might look into a patch for that.
Don't forget about permissions in Vista then — ask UAC or fallback to using temp.
That would be great, thx :). Most of the time I either use "Extract here" or I drag & drop the files where I want to, I find that much more convenient.
Hello everyone,
afaik this behaviour only occurs if you d'n'd from 7-zip to explorer. If you d'n'd inside 7zFM (two-panels-view) it extracts directly.
So if I'm right you would have to patch windows... ;-)
Best regards!
Yes, this happens when you drag'n'drop from 7-zip to explorer. But why is this a problem of windows? WinZip, WinRar, PeaZip all extract to the destination directly, instead of extracting to the Temp Directory and then tell the Explorer to move the files from there to the destination..
At least my WinRar do extracting to temp directory and then tell the Explorer to move the files from there to the destination. Just tested that. Don't know who failed with design though.
As for what I know this problem is common to all programs using standard Windows' drag and drop model, like 7-Zip and WinRar (I've not tested latest WinZip releases).
On PeaZip I have to use a custom drag and drop mechanism written ground up to work around this Windows' limitation; it basically catches the Explorer's windows path and send data there as a normal extraction/copy/move operation.
The tradeoff is that PeaZip can only drop data in opened folders (or desktop), not on icons or other applications, and don't shows Windows' drag and drop mouse pointers during the operation.
However IMHO the tradeoff is reasonable for this type of applications (that may deal with large amount of data, or sensitive encrypted information) since it allows to avoid writing data to unwanted location (secure deletion is not fast), does not temporarily need a double amount of free disk space and don't need to write the data two times.
IMHO the right way to solve this problem is to create virtual file system and present it as source for files. There is SDK for such task — http://www.pismotechnic.com/pfm/ But you will face perfomance problem if files will be accessed in non-linear form.
I'm wonder how drag-and-drop really works (never dig there), for example you can drop file to Word document and it will be saved in it — is it also working through temporary file? Another way to do this is through clipboard — you copy file to clipboard and paste in Word. (I pressed properties on embedded object and window says that it is located in temp folder) Also you can paste from clipboard in different formats — content can be created on paste operation, not on copy.
Why copy? It would be less of an issue if the files extracted to a TMP directory and were then moved to the destination.
No big deal, but maybee the program should default to the two-pane view that provides much better performance?
Maybe even a warning for big files in drag-n-drop mode?
Example: You have choosen to extract the 10GB folder "MYVIDS" to "c:\documents and settings\Administrator\desktop" the drive "C:\" only has 19.9 GB of free space, please extract using the two-pane view of 7-Zip File manager.