Enabling the option "prevent network folders from automatically loading" doesn't help if you don't exit DOpus (step 2 isn't actually needed). I just have to pull out the ethernet cable to let DOpus start freezing when working with local tabs because there are some invalid network tabs in the background. It's even not possible to close these background tabs without freezes.
Sometimes I end up with a running DOpus Lister having multiple tabs opened and it's difficult to figure out, which tabs need to be closed to get rid of the freezes.
For example in this screenshot I have to close two visible tabs (left and right circle) but one further that isn't visible (center circle) to get DOpus up and running again.
Switching to the basic pathfield (without breadcrumbs) can help, but if a drive is completely unresponsive then it's likely to still block an API call somewhere and force Opus to wait for the operating system to timeout and return control to it, so you'll probably still run into problems. Windows does not handle unreachable network drives well.
If I couldn't avoid leaving lots of tabs open for machines which I then disconnected from the network, I would probably close the window (or leave the window and open a new one, if the window is tied up for a while).
Actually DOpus does not freeze immediately when disconnecting the ethernet plug. If I disconnect the ethernet cable and come to back to DOpus 5 minutes later everything is still alive until I made some interactions (e.g. on the current tab showing a local drive). Then DOpus starts periodically freezing.
Would it be possible for DOpus to detect an unresponsible network drive and automatically switch such an unresponsibe tab to the lazy loading mode (which is only used on startup so far) to prevent DOpus from further freezing?
In this case DOpus will only freeze once and then the tab is switched to lazy loading to let the user decide whether he wants to give the drive another try. Maybe automatically if the tab actually comes to the foreground again.
Such a behaviour may prevent DOpus from freezing multiple times in a sequence due to the same reason.
Not really. The only way to know a drive is unreachable is to ask Windows to access it and then, after a lengthy timeout, get back an error. (There is a "disconnected" state for network drives, but it is completely unreliable and will say offline drives are online and vice versa often enough that it is not useful here.)
Windows assumes* that the network and the servers and shares on it will stay there. Network shares in Windows were not designed for computers which hop on and off different networks and have never been updated to correctly handle them. It's a problem of the OS, not specific to Opus.
(*The SMB/UNC/filesystem parts of Windows, that is. Other parts of Windows handle things better in their respective areas.)
Not really. The only way to know a drive is unreachable is to ask Windows to access it and then, after a lengthy timeout, get back an error. (There is a "disconnected" state for network drives, but it is completely unreliable and will say offline drives are online and vice versa often enough that it is not useful here.)[/quote]
I was a little bit ambiguous in my explanation. Obiviously there are thousands of reasons why a tab may be blocking due to any kind of API call. Thus my idea was not to directly check drives for reachibility. Instead DOpus may have something like a multithreaded tab-watch-daemon that "pings" each tab (e.g. once a second) to indirectly find out whether a tab has a problem due to an unresponsive drive or not. If such an unresponsive tab was found it is switched to lazy-loading mode to prevent further freezes.
Issue described here is still present and very annoying.
Devs, did you plan to make any improvement in area of handling network folders?
In my daily work I do a lot of things with remote machines / folders.
Directory Opus during attempt to access unavailable network folder freezes for dozen of seconds and completely no action can be taken.
It is very frustrating. I just bought pro license but this behavior made me very unhappy.
I found few tickets with this issue but in my opinion it is still not resolved.
It should be handled by background process or should be possible to cancel "frozen" tab by pressing ESC (for example).
Freezing whole application is very bad idea.
Also timeout should be configurable.
Please look how it is "resolved" in latest Total Commander. TC freezes for ~3 seconds and after that pressing "ESC" key immediately break further access to unavailable folder.
Much easier said than done, but we'll take another look some time in the new year.
Freezing whole application is very bad idea.
It should only block one window at most, for 30 seconds at most. Opening another window should still work if needed. Still not ideal, of course, but the whole program doesn't become inaccessible, or shouldn't at least.
Hi Leo
I know that it isn't simple. I have tested many file managers. Almost all of them handle network folders bad or very bad.
Total Commander (in latest version) is probably the best one. Previously it wasn't better from all other.
Also freeware Double Commander made big step forward in latest alpha version (0.9) - previous versions were very bad. On their web forum there is few posts about "how it is made".
But these two examples show, that it is possible to handle this scenario in user-friendly way.
I hope DO (which is definitely the best file manager on the market) will also handle this scenario more "user friendly".
Hello All.
In meanwhile I would ask if there is any detail log / trace file produced by DOpus. Where I can check what DOpus is doing and maybe this will help me with finding issue matter?
You can use Process Monitor to log and investigate which filesystem calls programs are making, with Opus or any other tools.
To answer your earlier question about timeouts, I'm not actually sure if you can modify them. There may be a registry setting in the OS but I don't know if changing it would be wise in terms of other things it might affect.
