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