I am seeing an issue with Directory Opus when accessing Dropbox folders.
Each time I delete a file, it takes an unusually long time for Directory Opus to respond.
If I try to delete files within non-Dropbox folders I don't see this slow down.
If I try to delete files within Dropbox folders but using the Windows explorer I also don't see this slow down.
I am using Directory Opus Pro 11.7 Build 5372 x64
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"
I am using Dropbox version 2.10.30
Does it only happen when using, or not using, the Recycle Bin?
It seems to happen whenever I touch a file using Directory Opus that's within a Dropbox folder.
It's the moment when I try to move on to the next file, I need to wait for an unusually long amount of time.
Does it only happen when using, or not using, the Recycle Bin?
Does it only happen when using, or not using, the Recycle Bin?
No this slow down happens whenever I change a file that is in one of my Dropbox folders. Change could be deleting or saving or renaming.
If you delete a file using Explorer, while Opus is also showing the same folder, does the same delay happen in Opus in response to the action in Explorer? Or is the delay only when the action is performed in Opus?
Yes, if I delete a file using the Windows Explorer, the delay is happening within Opus but not in the Windows Explorer even with both windows open (Opus and Explorer).
I created a short video of the issue. I would like to send it to you privately so that you can see first hand the specific slowdown of Opus when deleting, renaming or saving files within a Dropbox folder.
If you use ShellExView to disable the DropBox shell extensions, then fully exit Opus (via File / Exit Directory Opus) & re-launch it, do you still get the delays then?
I disabled the DropboxExt for the context menu which also disabled another icon overlay handler. I then restarted Opus.
After disabling the DropboxExt context menu, I do not see that slow down within Opus.
That seems to confirm the issue is within, or at least triggered by, the Dropbox shell extension.
If you want to find out if it's the context menu or the icon overlay, you can re-enable both via ShellExView, then add to context menu extension's CLSID into Opus's context menu block list.
To get the CLSID, right-click the context menu extension in ShellExView and choose Properties. The CLSID is near the middle of the window that appears. You can then add it here in Opus (more details here):
After doing that and restarting Opus, if the problem comes back then the issue is probably with DropBox's icon overlay handler. If the problem remains gone, it could be with the DropBox context menu.
I have tried to do as you suggested but it did not work.
I added the icon and the context menu to the ignore list but it does not solve the problem. I still have the delay only within Opus. Windows Explorer does not have this issue.
That indicates it is probably the DropBox icon overlay that is causing the problem. Leaving it disabled (via ShellExView) is probably your best option.
I have switched back to this version of Opus:
Directory Opus Pro 10.5.7.0 (5215) x64
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"
I do not have this problem with Dropbox within that version.
The solution that you provided me disables something within Dropbox that I need.
Do you know what is different within Directory Opus 11 when compared to 10 in regards to this particular issue that I am seeing with Dropbox.
There are thousands of changes between the versions, so one of the differences may be triggering a problem with the Dropbox extension. We're not aware of any particular change that should make a difference, however.
Opus does not talk to DropBox directly, it just calls a Windows API which requests the icon for a file, and Windows in turn talks to DropBox (and any other icon shell extensions).
I have this same problem...it's been bothering me for quite a while but I finally came here to search for the cause.
I'm also reluctant to remove the dropboxext that I do find useful.
I just wanted to mention that this is a problem for me too...so I hope GPSoftware does something about it and works around the issue internally! This problem doesn't happen in Explore (Windows 8.1) or XYPlorer (and alternative to DO I sometimes use).
It happens for me as well. Doesn't bother me too much, but if it can be fixed without removing or disabling the dropbox extension, I'm looking forward to it.
Thanks
It's worth reporting this to Dropbox, since the delay seems to be within their shell extension, when Windows asks it for an icon. It's unlikely we'd be able to tell why the delay is happening (even if Opus is somehow triggering the situation) as Opus does not call their code directly (Windows does), and we do not have their source code to see what it's doing.
