I've sent this yesterday to the DOpus support, but I wanted to get a second opinion, cause I can't believe a very basic operation like "move" doesn't work anymore. So maybe I'm missing something.
--- CUT ---
I've recently upgraded from Dopus v8 to v9 and I'm experiencing a problem which is extremely frustrating and dangerous.
This problem has re-surfaced again >:( I just installed v10.1.0 32-bit, to see if it helps, but to no avail.
Drag-and-drop folder moving from folder list always initiates a copy first, and when aborted files get lost forever, which is extremely frustrating. I can replicate the issue on my personal pc as well as my company laptop.
When did it resurface? With a new version, a config change, or something else?
Are you doing exactly the same as in your video from 2007? I tried doing the same thing without seeing any problems. (If I hold Ctrl while dropping the file, it gets copied and the original zip file is left in-place. If I don't hold anything then it gets moved, and the dir it was moved out of is left alone. Tested with a 1.5GB zip file on my local C:\ drive.)
What kind of folders are you dragging between? Are they on the same drive or different ones? Is it a network drive? (If so, which kind, a Windows server or something more exotic?) Any folder junctions, links or similar things involved?
Are your filetype drag & drop events still the defaults like in your original post?
Have you checked the Zip filetype, and the Archives filetype group, to see if either of them are overriding the drag & drop events?
I am not using any archives nor internal archives support. It happens on WinXP SP3 32-bit and Win7 64-bit.
It resurfaced around 10.2 or so I guess. It was bugging me for a while, but I didn't have the time to investigate or report it. But after losing some files today, I had enough. Afterwards I experimented a bit and found out it happens when I drag and move any folder out of or within Temp folder (%TEMP%=D:\Temp); dragging files from outside is working fine. I use the Temp folder a lot, and apparently some copying logic has a %TEMP%-specific bug. Maybe you can reproduce it too.
I tried below %TEMP% but didn't run into the problem. Here's a video of what I did: Moves_in_Temp.mp4 (7.5MB)
10.0.2.0 I presume (we're only up to 10.1.0.0 so far).
The filetype events may still be worth checking quickly. Even if the internal archive support is turned off, if the Zip filetype (or Archives filetypes group) is overriding the Drag & Drop events then it might be a factor.
(Don't worry about the double-click events, though; it's normal for them to be overridden and they would not affect drag & drops.)
Here's how my filetype drag & drop events are set up:
Now that I think of it, there are also shell extensions which can modify what happens when files are dragged. You can use ShellExView to find out which extensions you have installed and temporarily disable some to see if it changes things.
If you sort ShellExView by its Type column, the ones of interest are the Copy Hook Handler and Drop Handler ones. (There are also Drag & Drop Handler ones, but I don't think those matter in this case.)
(If on a 64-bit machine, be sure to use the 64-bit ShellExView.)
You can usually ignore the Microsoft ones, and the Opus ones as well of course. There's an option in the View menu to highlight non-Microsoft ones to help focus on the extensions that are likely to be more unusual. Here's what I see for the two relevant extension types:
That's the first time dragging folders or the folder tree have been mentioned in the thread. Did you mean folders, or files? The folder tree, or the file display?
The video shows only dragging files in the file display so that's what I've been trying with at all times.
Thank you for taking the time to investigate it and reply back to me, I appreciate it. Btw, I meant 10.0.2 I have gone through all the tips you gave, to no avail. Maybe it was not clear in my post, this is not exactly the same problem from my original post in 2007 and not what you have tested in your video. I am not using Dopus archive support at all. But I have done some experiments and isolated it to a single configuration. It is confined to the folder the TEMP environment variable points to and only folders dragged-and-dropped using Folder Tree are affected.
But mind you, user's env-variable overrides system variable with same name, and changes in env-variables values do not have any effect on already running programs. they must be restarted. Just to make sure, I used a program called PowerPro which has "refresh environment" function (probably just broadcasts "WM_SETTINGCHANGE"), restarted Dopus every time, and checked the value it is using with Process Explorer->Properties->Environment. Other environment variables seem not to be affected at all, only TEMP. I have uploaded a video here. Can you replicate this?
Now that the problem has been specified, I can reproduce it. At least, I can reproduce that if you drag & drop folders around in the folder tree, below the temp dir, then they are moved via a copy-then-delete instead of a rename.
Is that the extent of the problem or is there more to it than that? You said the original problem from 5 years ago had come back, and that had the parent folders being removed when they shouldn't be, which I haven't seen happening and I don't think happens in your new video. So I think it's just the copy-then-delete making things take longer than they need to when done via the tree below temp, and nothing more?
The reason why I said "original problem" was that I haven't paid much attention when and how this is occurring, and thought it was a general drag & drop problem again. That is until I invested the time yesterday to narrow it down.
Okay, that should all be fixed when 10.1.0.1 is released, after the work I've done on it today.
Opus was treating drops from the folder-tree, below the temp folder, as if they were temp-files dropped from other programs, which it handles differently to normal drops.
(That is also why it deleted the files at the end, even if not successful. If one program moves a temp-file on to another program then it's saying it doesn't want the file anymore, and if the target program doesn't delete the file at the end then it is often left wasting space in the temp folder until the next time it is cleaned. We only do that with the temp-dir though, since files in there are assumed to be expendable, i.e. can be deleted without issue if given to us in a Move operation, as they're only temporary and no longer wanted by the source program.)
As a general note, it may not be a good idea to use the temp folder as your own working folder, as there are assumptions made about the kind of data in there (not just by Opus but by other programs as well; something cleaning old files might delete a bunch of things you just extracted below temp if the extracted files' original dates were preserved, for example). I make a separate scratch folder myself. But this particular thing should be fixed in the next update, either way.
