When editing a file name of e.g. a *.jpg file I frequently see the following issue:
Highlight file --> F2 --> type "new name" --> Enter
Instead of changing the name the filename "snaps back" to the old name. It then stays "old" for a long time (up to 3 minutes) and then suddenly changes to the new name.
I observed this in both DOpus 12 and DOpus 13 beta. I happens particularly often when the file-preview pane is open and / or the file was opened before renaming.
Note however, that I double checked and this occurred multiple times with the file being definitely not opened in any other appliction (MS Excel of XnViewer).
To me this issue is serious as it breaks my workflow as I cannot be sure that the file has been rename / moved and have to literally "wait and see" like a monkey ;-).
Any help or ideas would be greatly appreciated. Note that I've been using DOpus for like 10 years and this issue is new, but I can't pinpoint it to anything.
Very good question - sorry I forgot to put this in right away.
Unfortunately, this happens on a local drive (one of the fastest SSDs currently on the market): WD SN850X using PCIe 4x4. Thus the SSD is not the issue with very high probability.
Thanks also for the tip - I will generate process snapshots, but since this error occurs randomly (and in bunches, i.e. it may be good for a complete working day, and then happen 10 times within 1 hour), so I can't promise when I'll have them.
That's normal with 13, and nothing to worry about. One instance handles desktop double-click and the other exists to collect crash reports if something goes wrong.
Looking at the DMPs you sent, Opus is asking Windows to move/rename the file, and that is then not progressing for many seconds:
That indicates the problem is outside of Opus, and likely an issue with one of the following (or a combination):
A bug in the OS itself.
(Least likely option, since you'd probably see a lot of things doing the same thing.)
A problem with the drive in terms of hardware, cabling, insufficient power, or just corrupt data.
(Possible, although I'd expect that to manifest in other ways as well. And power is less likely when just renaming something rather than copying large amounts of data.)
(It might be worth looking in Event Viewer for any warnings or errors related to storage in the Windows Logs / System category. If there's a hardware problem, you'd usually see some indication of it in there if you scroll through the last day or so of events.)
(Note that not all warnings in Event Viewer are an issue. It's unfortunately routine for Windows to log some warnings into the log when nothing is actually wrong, thanks to Microsoft never fixing their logging. But ones indicating drive or storage controller resets or timeouts are not normal, and would indicate a problem somewhere in that area.)
Antivirus / anti-ransomware or similar intercepting the request and going wrong in some way.
(This would be my bet, based on what's known so far. Antivirus etc. can treat different processes and versions differently, and also reacts differently depending on which files are being touched.)
I think I have narrowed it down or maybe even found a solution (I'm still testing though):
My new SSD (Western Digital WD_BLACK SN850X NVMe SSD) has a feature called "Gaming Mode 2.0"
According to the WD homepage:
Once enabled Gaming Mode 2.0 Detects gameplay and enables game-specific performance features in firmware such as Predictive Loading for even faster performance & Adaptive Thermal Management.
I don't really know whether this can explain it, but I have disabled this setting and haven't experienced the delay / freeze since then.
