Windows 10 latest, dopus latest, pro version. After a long period of stability, on a routine rename of a folder, dopus responds with "not responding" and then unable to stop the app through normal means. After a reboot, same situation. Decided to uninstall and re-install to start again.
Dopus now starts up, but "not responding" on most things.
Process explorer (sysinternals) virustotal is clean.
It looks like the program is hanging when it tries to check if M:\desktop.ini or M:\folder.xml exist (to see if the drive is a virtual folder).
My guess is there is either an issue with the drive type itself (e.g. Google Drive File Stream has some very strange behavior with desktop.ini files, which it generates on the fly) or antivirus is getting involved and freezing the process for some reason.
M: is an old laptop running Linux Mint that has a samba share defined for a folder on it. I found that it was in a "completely lights out" state and powered it off and on to get it up and running again. Apart from dopus behaving strangely, there was no other indication that anything was amiss.
Apart from mapping M, I can also access the shared folder with \192.168.1.137\TestShared and wondered if there was a best way to access it, or configure dopus to behave in a different way.
Am also wondering if it would be useful to find one of these monitoring tools that pings devices on my network and alerts if they aren't found rather than dopus being the one to experience the worst aspects of a device not being available.
As ever, a great learning experience, and thank you for looking into it.
It being a network drive is strange, since the test should be skipped for network drives. Is it mapped in the usual way via Windows?
It can take up to 30 seconds for requests to read files (etc.) on an unavailable network drive to fail (after that, the OS usually caches the fact the machine is not available, at least for a while, so subsequent attempts to access it fail much faster).
Either is fine, but if it's a device that's not always available then using the UNC path instead of the drive letter maybe best. Having a drive letter there means things start looking at it automatically (e.g. to get the label and icon if the This PC branch/folder happens to be shown somewhere), while UNC paths are generally only accessed explicitly. (Although a favorite or similar pointing to a UNC path can trigger the same kind of issue as well, it'd only be when displaying the favorites list.)
Normal mapping for M using dopus Map Network Drive, but for now have deleted the drive mapping for M, and will use the UNC path. There would normally be a tab open in dopus for it using the UNC path.
That dialog isn't part of Opus; it's part of Windows. Opus just asks Windows to display it. You can open the same thing via File Explorer, which should behave in the same way.
Fully understood. Just looking up how to get rid of it from Windows means it is one to be lived with. No more network drive mapping for me. Anyway all looks back to normal for the moment, so a big thanks!
Here's the dopus response to Disconnect Network Drive (this would be the same in Windows Explorer):
And in the admin command prompt:
c:\>net use
New connections will be remembered.
There are no entries in the list.
c:\>net use \\readynas01\stuff /delete
The network connection could not be found.
c:\>net use
New connections will be remembered.
There are no entries in the list.
c:\>net use \\readynas01\stuff /delete
The network connection could not be found.
Strange, as is the error message with random characters in it. This is a Windows issue not an Opus one, so you might find someone who knows more or has run into the same thing on a forum like SuperUser, perhaps.