...compared to how long it takes on windows explorer (10s vs 2s).
Here a screencast showing the issue
Same goes for navigating inside the folder tree; it's really unworkably slow, even on my fast (400 MBit/s) connection.
Many thanks and keep up the good work!
Do ask if you need any more information
Is it still slow if you turn on Preferences / Miscellaneous / Windows Integration / Hide Windows items on file context menus (shift overrides)?
If it's a lot faster then then the problem is probably caused by a shell extension something has installed: Crash, exit or high CPU when right-clicking certain files
No, it's not, many thanks for that quick solution.
The other issue remains - when navigating through folders, in some occasions their contents take three or four times as long to load in DO than in WE. Any suggestions for that as well? If wanted Ill record another video.
Best regards
It's possibly a shell extension causing both problems. I would follow the guide I linked to track down which one was causing the right-click problem, then see if disabling/updating/uninstalling it solves the other problem as well.
Just to be sure - the issue is not present in Windows explorer, and also, it's still present when I turn on the "hide windows items" setting. Shouldn't that fix it?
In that case it might be something else.
Could you generate some Process Monitor logs of what happens when you change folder, and separate logs of when you right-click something? Those might reveal what's happening.
Please let us know the path of the folder that you navigated to, and the file or folder that was right-clicked, so we know what to look for in the logs.
Looking at the logs, the problems with that network drive seem to be affecting everything. Maybe Opus is doing more than other programs, or the other things tend to be in the background (e.g. Dropbox), but the problems seem to affect everything. The drive (or possibly network) is just very slow for some reason. This also ties in to what you said in the private message about right-clicking taking a long time in Explorer.
It's normal for some operations to take a long time, but not things like CreateFile, so he's an example where I've filtered Logfilenavigation2.PML for CreateFile operations taking longer than 0.1 seconds (which should usually return almost nothing):
You can see it's affecting everything that accesses the network drives, not just Opus.
Focusing on dopus.exe, it seems particularly slow when Opus is asking if NTFS Alternate Data Streams exist on files. While this is done on a background thread, it makes me wonder if the drive is blocking other requests while it deals with those in parallel. Querying if an ADS exists should not take any longer than asking if a normal file/path exists, but it's regularly taking a tenth to a quarter of a second per file on that drive, from what the logs show:
It's possible the drive doesn't support NTFS ADS, but then it should be very quick to report that the ADS don't exist in that case. It looks more like a bug to me. Whether it's the underlying cause or just another symptom of a more general problem with the drive, I can't say, but i would talk to the vendor as it's definitely not normal.
Turning off Preferences / Favorites and Recent / Labels / Enable label storage in the file system (NTFS volumes only) would prevent Opus from looking for that ADS data, which might be worth a try.
It's also possible the network or firewall is involved in some way, since other drives in the log seem to be quite slow as well. e.g. There's a sequence of three 1 MB read requests on a file I can see on one server which took 1.7 seconds, 3.2 seconds and 5.1 seconds. Unless that server is on a very slow (or high latency) connection, that seems a long time. (n.b. That was something a service in svchost.exe was doing, not Opus.)
So I would say you're looking at a general issue here, not specific to Opus, although Opus may be more visibly affected than other software.
Many thanks for that detailed report. I have understood that, as the server is not under my control, there's nothing really I can do. I tried accessing it over 2 different network connections, but no difference there (both over vpn, should that be relevant).
