I am getting this message very often. Started within the last month or so.
Tried to research the message and not finding any explanation.
Message:
"An operation is taking longer than expected."
"Operarion: SHGetFileInfo"
"{679F85CB-0220-4080-B29B-5540CC05AAB6}"
I'm using Version 13.7 x64 Build 8944
The only possible cause I can mention is that I have a USB Drive plugged in. If I unplug it, the error goes away. When I replug it in, seems back to normal.
Can someone help me to find the trigger and the fix? Thank you in advance
{679F85CB-0220-4080-B29B-5540CC05AAB6} is the Windows shell's internal name for the Quick Access folder (renamed "Home" in later Win11 updates).
Maybe something in that is pointing to something that cannot be resolved. For example, paths on a network server that is not accessible.
Check what's in the folder in File Explorer if Opus is having trouble displaying it. It's also possible something is wrong with the folder itself, which might affect File Explorer as well.
Unmap the drive. Windows will cause long delays if it tries to access a network drive that isn't there, and having it mapped as a drive letter will cause things to access it (e.g. just asking the OS for the drive's icon when showing a list of drives can cause a 30 second delay).
Using UNC paths (the \\server\share\dir... type paths that you map drive letters to) directly is often a good solution to the problem, as it avoids the drive letter which is the cause of many problems. Of course, you still need to ensure nothing tries to access a UNC path that isn't available, but that's easier than with a drive letter where it can happen implicitly rather than via explicit actions. Drive letters for network drives aren't really needed, and personally I haven't used them in about 15 years.
I second that : I used to have so many mapped drives, but that brought me more annoyance in the end.
I had to change because I had then too many internal/external drives connected, and went on the UNC paths route.
To ease everyday use, you can :
assign aliases to these UNC paths to make them available more easily
if you're more a mouse guy than a keyboard guy : make a button (command GO /myNetworkDriveAlias if you made an alias or GO \\server\share\dir1\dir2) or a menu button with several entries (each one with a GO command to access either multiple drives or multiple common paths on this network drive).
Hi
I borrow this thread instead of starting a new one.
Since I upgraded to Dopus 13, I got similar issue too when I accessing the network drive on my work computer. Delay can be up to 30 seconds and sometimes the Dopus screen gets milk white under this time. Accessing C: works fine, it's only network drive it occurs on.
Dopus 12 worked fine without any issues.
There's also additional information in that dialog if you use the latest beta version.
Opus 12 would generally have had similar delays if the same operation was triggered, it just didn't tell you or give you a chance to cancel the operation. The issue is that any request involving a server that isn't accessible can take up to 30 seconds to timeout in Windows.
I am experiencing this fairly often with v13 on a new network share to a computer that has an M.2 storage drive. I'd never seen this before this setup. This issue isn't so bad, except that, there's a bug that causes it to open up that requester on many unrelated dopus windows, not just the one in which the copy function is triggering this. On multiple monitors, with dopus windows on them, it's very disconcerting.
Is there a way to disable this requester, or set it's timer duration before trigger?
But changing that will just mask the problem. Working out which operations are delayed and solving that is better than allowing longer delays before you're told something is wrong.
I don't think that's possible. The dialog is shown specifically by the thread that encounters the issue. If it's happening in multiple windows simultaneously that suggests its being caused by something other than the copy.
Typically I have 6-8+ listers opened on 3 monitors. The specific lister that almost always triggers it is a dual lister (on Computer A) where I'm copying from a network share on Computer B (M.2) to a network share on a NAS.
The other listers would all be single listers to different shares on the same NAS. The two specific shares being copied between above are rarely being used on any other listers. And rarely that any other files would be copying in these other listers.
Note that, previously I had a different Computer B with a regular harddrive, and never saw this happen.
By default I have the copy progress minimized to the lister status bar. And it's usually in that state.
When the issue happens, the listers on the other monitors, even if they're behind other windows (they often are), will come to the front, show the error message, sometimes flash behind/front other windows, and after a few seconds, go away on all listers. It's very startling.
I'll endeavor to try to figure out if there's something in common with the listers, but the setup is pretty much the same all the time it happens. But it's so quick it's hard to see specifics.
One additional comment... when the issue is likely to happen, if I attempt to rename files in the source side of the dual lister that is copying files already, it can take a long time for them to rename... 5-10s. My typical process is when the files are available to be moved, I perform a rename function on them, and then move them to the NAS. These are files that are being generated on Computer B, and to limit storage space being used on Computer B, I'm moving them to the much larger NAS. I have had it happen a few times, that I do the rename, it looks like they are renamed, so I start to move them, and then as they come up in the transfer queue they error that the file (old name before rename) doesn't exist.
An update on this, having just happened 3 times in a row. This one was a little different as I don't have many listers open (after a reboot). On Computer A, one double lister copying files from Computer B to NAS1 - did not show the warning message. Two other listers open with views of two different shares on NAS2, doing nothing at all. One at front, the other behind out of view. Both display the warning, with the behind lister coming forward into view while showing the warning, then going behind again.
I just noticed that there might have been a little more going on... The double lister may have been doing two simultaneous copies... one series Computer B to NAS1, and one series Computer B to NAS2. This would explain the tie in with the other two listers showing the warning, since they are also NAS2.
Hi
Sorry for late reply.
I have update to latest version on my work computer.
I think it says something about parsedisplayname.
At my home computer I noticed that I got delay to my NAS, just blue spinning wheel but no requester. Also delay with context menu up to 30 seconds it feels like
