App freezes when network storage unavailable

Help & Support
1

Hello,

First of all, I want to say what a lovely and well made software this is, a lot of thought has gone into it. But there's several things that I have issue with, one of them is the following.

Whenever a network folder that is open in Dopus becomes inaccessible, Dopus freezes for a good while.
For example, I have a tab with network folder open through a UNC path. I shut down the server. What follows is that whole Dopus becomes unusable. First, it will freeze for ~30 seconds, then, if I click anything at all inside the app, it will first freeze for 30 seconds, then perform the action, on the next click it will freeze AGAIN, and so on.
So I manage to open a new tab, as I have unfinished business, but I want to use the computer while the server is offline, but the app STILL freezes on every click when the aforementioned tab is not even in focus.
While I don't care about that folder, as the server is down obviously, it is not the tab that freezes, it is the entire program, the entire program stops responding for 30 seconds or so after every click.

Is there anything I can do inside the app to ameliorate this or can you do anything to make this not happen?

Thanks.

2

Windows will block for 30 seconds on requests to access network servers that aren't there anymore. We try to do it on background threads but it's not always possible to prevent some part of the UI thread from depending on the result, which can cause delays.

You can usually open a new window even if the old one that was pointing to the gone resource is temporarily frozen.

One thing to avoid is mapping drive letters to network shares that won't always exist. That will cause problems with anything that lists the drives (e.g. the folder tree, or drive buttons on the toolbar if you have added those). That includes others fotware, not just Opus.

Beyond that, just make sure you close windows/tabs pointing to servers before shutting them down to avoid having to wait for the timeout.

(It's also possible to change the timeout in Windows, I think, via the registry. 30 seconds is much longer than it needs to be if you only access machines on a LAN.)

3

Thanks for the instant response, I didn't get around to testing and writing a reply right off but I immediately tried removing the drive mapping, it freezes less but still happens. The only reason I use the drive mapping is because there are some old software that have an open/save dialogue box that only allows you to access something that's on the provided browse list (you can't enter a path), which is rare, but there are some. Nevertheless, it's removed now.

Unfortunately I always keep a lot of tabs open (or folder windows in Windows Explorer before Dopus (I had them set to reopen on restart)), because I can go do something else, shut the server down, and when I need it, I fire up the second storage server and switch to previous context.
I will look into lowering the timeout as a patch as well, thanks for that tip.

I guess I did not not realize that Windows' idiosyncrasies have anything to do with Dopus; I thought it uses its own internal functions for everything. Also why does the main software stop responding instead of only the affected tab (like Chrome for example)? I would think each tab is a separate program with its own main UI context.

This does not work as the new window freezes as well until the first one unlocks. I tried opening File Explorer, and that works during the time Dopus is locked up - I can browse a different SMB server.

:woman_shrugging:

P.S. With a Dopus freshly reopened, Dopus freezes with the inaccessible-server tab open, even though it says the "network folder has not been loaded automatically". If I close this tab - which isn't loaded, it stops freezing. This doesn't make any sense to me.

4

That sounds like something in your folder tree or on your toolbars is trying to access the network share.

Folder tree: Most likely Favorites or Quick Access, if they are shown in the tree and the tree itself is turned on. Makes sure there's nothing pointing at servers that don't always exist.

Toolbars: If you've created custom buttons, make sure none have commands or icons that reference servers that don't always exist.

5

Well, naturally, I have a shortcuts for all of my network storage - it saves a lot of time.
You are saying I should not have shortcuts for network storage? That is like saying I should not have a bookmark in a browser for a site that might go down (I have hundreds that have stopped existing over time).
This would also mean that I should expect the app to freeze if I plug into a different LAN/VLAN (that's not connected to the first one) without closing everything and reopening it when I reconnect to the first one?

6

It's best to avoid shortcuts to servers that won't always be available. If you try to access one, Windows can block for up to 30 seconds, with no way to cancel the request. (The best any software can do is make the request on a throwaway thread, and provide a way for the main thread to stop waiting for it while the other thread continues to hang until the timeout.)

If we're talking about toolbar buttons, it is possible to make buttons that go to those paths which won't cause problems (at least unless you click on them) if you really need them.

7

Hello all. Please look historical posts. It was reported in the past many times. I have tested many file managers. Sadly, but true. Only Total Commander handle inaccessible network paths properly. It looks like TC handle all connections in background task. If network path is not accessible for few seconds there is no whole app freeze but you can easy press 'ESC' and break access to this path. Or you can simple do other things because app is still responsible. To be honest: I love DO, I have purchased license for both (TC and DO). Some features are better in DO, some in TC. In DO I am still waiting for better handle inaccessible network paths... It CAN be done better - please check free TC version and look how this should be made.

1 Like
8

If you can identify specifically what it is in your configuration that's causing it then we can certainly try to improve things.

1 Like
9

I am ready to help, do you have idea how to check, compare with TC? What tool to be used? What logs to be captured? In the past I have some ideas that dropbox app integration with windows explorer can made things visibly slower. But definitely - I have tested TC for few last months and I never seen whole app freeze, so maybe it is special secret how things are done in TC, but it is possible.

1 Like
10

I have tried in the past sysinternals filemonitor but for my understanding of his output there was no clear point where whole DO freezes. Maybe better idea is to attach debugger and play with code directly? I understand that if path is inaccessible it can't be opened and one tab (best possibility) or one window (worst possibility) can hang. But it shouldn't affect whole application. Probably only one solution is to spread this into different threads. Not so simple. But I have no other ideas.
There is yet one example: free double commander. They are trying to handle inaccessible paths like TC and in some cases it works, but not always.
If you have any idea how to help - I am ready

1 Like
11

As Leo's said, the problem is that any attempt to access (which includes things like, obtaining timestamps, file attributes, filenames, icons, file types, etc..) an unavailable network drive can result in a freeze. The only solution is to move the action that triggers it to a background thread. We have moved many things to background threads already, but it's possible there are still others that could be changed. That's why I said "identify specifically what is in your configuration that's causing it". Maybe it's a toolbar button, maybe it's having the folder tree open with a particular combination of flags, maybe it's the result of a shell extension you also have installed. We need specific information that will let us identify where the trigger access is occurring.

Sending us a process snapshot from when the freeze occurs can also be helpful.

1 Like
12

@gawkla I'm glad I'm not the perfectionist here, lol.
I hope it can be appreciate that from a user's perspective it is very irritating for their program to freeze because of something on the other end. It is a basic concept of a DoS. Good software is robust!

I think it would be great if it did that, showing "Reading folder..." while something else is called to fetch the data, instead of the former freezing itself.

I've tried to compile a bit of info below to try to narrow it down.

I do not have any "aftermarket" toolbar items, as I'm still pretty new to Dopus, mostly everything is default. I do have favorites that include unavailable drive. I have previously removed mapped folders and mapped drives. I have also included a screenshot of the interface, so you can check, because I don't know what might be tripping it.

Regarding identifying what's causing it, the simplest first: open tab to the server, disconnect server from the network, try opening inaccessible content -> Dopus freezes for 30seconds before either going to "Reading folder..." with an abort button or simply ignoring the action.

Situation 2: Dopus is open, network storage tab is open in the left pane and in focus. I close Dopus. I disconnect the server. I open Dopus, left pane is initially empty (even if an available folder is open there), right pane shows items, Dopus now freezes for ~45 seconds (not responding), then finishes opening with the network tab "unloaded" - why is it freezing if it isn't even loaded? This happens every time it is reopened in this state, not just the first.
Okay, I waited that first freeze, now the tab is definitely "loaded as unloaded", I open a new tab in the left pane, over the unavailable tab, and do whatever. It will now freeze randomly for 30 seconds. As long as that "unloaded" tab is open (not selected) and I'm using Dopus, Dopus will randomly freeze every 30 seconds or so for 30 seconds. I right click the unavailable tab and close it, Dopus no longer freezes now.
While it is frozen, if I open a new Dopus window, it is also frozen as long as the first one is.

I will gladly provide further info if needed.

Dopus
Dopus1280×987 135 KB

13

It does that already for reading the folder. Something else may be causing the problem.

You could make some process snapshots which may reveal where the issue is coming from: Manually generating process snapshots

14

very well described.

I have identified this scenario:

  1. connected to work via VPN, have many tabs opened to remote folders.

Next VPN is disconnected.

If try to access any tab with previously opened remote folder => DO freezes

Even worse: if you have 5 tabs, each starting with N:\Documents... even if you wait till DO unfreeze, accessing to next tab freezes again whole app

In other words:
If you try to open new path which is unavailable everything looks ok (there is info "reading folder" and you are able to cancel this). But if you have open tab with remote path and this path became unavailable whole app freeze.

1 Like
15

Thank you!
Ths is a very good example - something craps out and you lose connection to VPN, but no only that but now also the file manager stops responding simultaneously.

Thank you, I've made some snapshots, uploaded them and PMed you a link, if that works for you.

16

The snapshots show that this file has been double-clicked:

\\192.168.x.x\Test\Docker Desktop Installer.exe

That'll cause Opus to try to access the file, and if that server is not on the network then it'll cause a delay.

But it seems to be happening because an .exe file on a server that doesn't exist has been explicitly double-clicked?

18

Correct, this corresponds to the first situation I mentioned:

It happens when an action is performed on an inaccessible content, I understand it cannot access the file, but the issue is that the whole Dopus freezes and goes to not responding - cannot even cancel.

I guess I should have made the second snapshot as well when it freezes on its own, which is situation 2. I will snapshot that as well and upload the dumps.

19

Our goal isn't to make every single self-inflicted problem immune to freezes due to an unavailable network drive. Our intention is that there should not be any freezing if you open a new Lister that tries to load a network drive by default, or when working in other folders. There'll always be a way you can force a freeze if you try hard enough, because the freeze is built into Windows itself.

20

True, but please rethink provided scenario: you have opened tab with remote content. Next this content became unavailable (disconnected vpn, server unavailable etc). Now this scenario provide whole app freeze. But in my opinion shouldn't.

1 Like
21

Okay, apparently I have different views about bugs than the rest of the world. I'm tired of bug reports that everyone fights and that get closed on Github by bots if nobody says anything every few weeks, I'm outta here. Hope everyone had a nice Easter.