Try to open a non existent network folder, for example \\192.168.1.2.
Whole DirectoryOpus hangs for a minute, and then shows "An error occurred reading folder" error.
It would be fine if only a tab was hanging, like it happens in internet browsers for instance, but it is not nice that the whole application hangs. And after I get an error message, there is no way to close this tab, if I double click on it to close, DirectoryOpus starts connecting to it and hangs again (restarting the application helps)
At a script level it would be nice if there was a way to limit how long DOpus.FSUtil.Exists(somefile) keeps checking for an item in a non-existent location. A timeout parameter perhaps?
I don't completely agree. Even though Windows API doesn't directly provide IO calls with timeout, it has async IO operations, which allow to implement DOpus.FSUtil.Exists(somefile, timeout).
Also, I don't know how Directory Opus is designed, but, for instance Windows File Explorer doesn't hang if I try to access non existing UNC path. So it is more a design issue that if a tab hangs, it hangs whole application. It is not related to WinApi functionality, in my opinion.
Therefore I consider it a bug. It doesn't mean that you must fix it, but still, would be nice if it was added in the list of bugs.
GetFileAttributes is what is typically used to test if a file exists. There is no Async I/O version of that, nor of most other APIs. Async I/O is mainly for reading and writing data, not for everything.
The only general way to add timeouts to the Windows file APIs is to call them on another thread which can be abandoned if it takes too long, but that can lead to other problems. (We do do that in some places.)
It shouldn't freeze the whole program, at least not usually. It may freeze one window for 30 seconds, if something on the window's UI thread (or which the UI thread is blocking on in turn) tries to access a network server which doesn't exist.
We've moved a lot of that kind of thing to background threads, but not everything. (We've also found that moving things to background threads can introduce bizarre compatibility issues with shell extensions and cloud storage software, so it's a double-edged sword.)
You should be able to open a new window and use that while the first one is waiting for the OS's 30 second timeout.