Opus 9.5 on XP64 but it's done this for a long time under old versions and on x86..
When I had Opus open last, one of the tabs was to a share on my laptop.. \bob-g2s\D$ I close the lister, shut down my laptop, and go home.
I am now VNCing into my workstation from home, and try to open a lister. Opus remembers the root tabs and tries to open the share in one of them.. but obviously that whole computer is not even on the network. Opus will sit there, locked up, for over a minute before it finally frees up and lets me select some other path.
Why is this timeout so long and why does it deadlock Opus completely until it does?
Excellent, This is what I have been looking for some time.
What is odd is that dopus can provide an error message stating that "Tha network path was not found." but still attempts to load it. I would expect that if the situation of a network path not found is detected it would either close the window or open C: or something.
"They long network timeout isn't set by Opus but comes from Windows. It should be possible to change it but I'm not sure where that is done."
I have to wait often too, I already looked into windows to find any registry settings or something to edit the share-timeout value.
Did not find anything, not even with the help of google. Do you guys know where to find this secret ?! I'm on Win7 x64.
Using the 'Prevent automatic loading of certain types of folders / Network' didn't change anything.
I'm aware that the delays come from the operating system, but even windows let you open a new explorer to get to your files/locations etc.
I guess it is really hard to let every lister work in its own Thread or Process so it does not block the whole application.
I really like DO but I hate its network behavior.
An update regarding this problem would be highly appreciated
Listers already do run in their own threads. Is the whole program unresponsive, preventing you from opening a new window, or just the window in question (preventing you from opening a new tab or changing folder until the timeout)?
Open a new tab and go to a remote resource on a actually present machine, i.e: \myMachine\d$
Now turn off the remote machine or simply disconnect the remote machine from the network. Try to make a refresh F5 or access a directory: The whole lister/app will freeze.
I'm working a lot with test hardware, and VPNs. It happens nearly every day that I keep a tab open with a machine that is no longer present in the network or the required VPNs has disconnected. I got used to it to keep a tab on a local drive on every view (i'm using dual view), so I can click on each 'local drive' tab and use 'close all other tabs'. Otherwise it will freeze...
I just realiced: You said that every lister runs in its own thread, what about the tabs?
Not sure if tabs are on their own thread but they have to share things like the address bar with other tabs in the same window, so it probably doesn't matter in this case.
Are you prevented from opening another Opus window (not a tab in an existing window but a new, separate top-level window) while in that state? (e.g. Via the tray icon, desktop context menu or desktop double-click.)
Thanks for the tipp. Now my DO is freezing in two windows.
I still can open a new DO window using the taskbar, but since DO restores the last 'session' the new window will also freeze
On my system it is a bit different, Opus hangs occasionally when i drag a network-file out and drop it into
another application, which might analyse or seek trough that file first (movie files for ex.). Whatever happens
(in that app?) makes DO freeze up. If the application is having a problem looking that dropped file up, it should
not bother Opus, doesn't it !? The Opus lister was responsive before the dragndrop operation and is so
afterwards, when the other app comes back to life.
I don't know how dragndrop works in detail, if there is some "handshaking" between Opus and that application
happening, and the application is just late in telling "ok, got it!", then that is rather not Opus fault, but
perhaps there is another kind of implementation possible or even realized and my assumption is wrong.
Drag & drop with a working network share isn't really related to this thread. If you want someone to look into that, start a new thread (or a support request with GPSoftware if you want them to look into it rather than people reading the forum) and provide more detail, e.g. examples of what you are dragging and on to which apps.
FWIW, drag & drop on Windows is a mess and both programs can be tied up while it happens, depending on the type of data being exchanged. Opus usually uses a dedicated thread for doing it, though, so it shouldn't lock up the Opus side, but maybe you've found a case where it does.
