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
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
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
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
@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.
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
very well described.
I have identified this scenario:
- 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
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.
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?
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.
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.
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
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.
As a user it's entirely reasonable for you to expect no problems. As a developer, it's entirely reasonable for us to accept that some problems are unavoidable. All we can do is try to improve things where it's practical and possible. Complex systems can never be completely perfect no matter how much you might wish it were different.
1 Like
finally: can we expected better handle this scenario or it is "working as designed" and will be leaved "as is"???
Dopus is basically unusable when using a low bandwidth/high latency connection (while not transferring anything, just browsing local files), freezes and lag every few seconds. Dopus out the window for remote work. Had to switch back to File Explorer.
I've found everything unusable in that scenario. File Explorer isn't as affected (but then it displays less information about files) but still doesn't work great either in my experience. SMB just isn't designed for high latency networks, IMO.
FTP or SFTP are a better protocol for internet file transfers.
...but as long the button/command is not executed it shouldn't matter if it refers to a non-active networkshare. I've never noticed such a behaviour.
For example when I have a simple "go \\myserver\data" or "\\myserver\app.exe" as button it does not make DO freeze as long I don't use it.
Program interface shouldn't freeze, I don't care about the actual data coming in or going out, the main interface shouldn't freeze. Forget about using SMB during this time -- the program is unusable for local browsing. At most, the affected subsection should freeze, like a tab, a button or a shortcut. This is not robust programming.
That isn't true at all, unless you mean "while waiting for SMB to time out", which is a different statement. Even then, you can just open a new window and use that if you don't want to wait. The whole program doesn't freeze, just the window that's waiting for a network drive. I've seen the same thing in File Explorer, and it's quite difficult to avoid the UI thread from ever calling or waiting for any code-path that might even glance at the filesystem (usually instant but will take 30 seconds for offline network drives sometimes, if Windows hasn't cached the fact it's offline). We try to avoid the main problem cases, but we can't avoid them all. (Especially with examples like earlier in this thread, where an exe file on a non-existent network share was double-clicked!)
1 Like