after some changes in my intranet my NAS uses new pathes. When I open listers with tabs linked to old pathes (which arent't of course not valid), DO needs a terrible long time until it's responsive again. That's a common problem with DO in an network environment. It should be possible to cancel the connection buildup. Any hints?
And I want to ask what is the most convenient way to change the pathes of all my listers? Editing the XML-files directly?
AFAIR timeout/searching is controlled by Windows, but I have no delays. E.g. when I'm trying to connect to an unaccessable UNC-path, DO either immediatley shows a message that the path/device is not available or I can press "cancel" in lister.
But I notice a delay and can't cancel immediately, when a device is available, but the HDD is in sleep-mode. In that case I have to wait until the disk spins up. Maybe that causes your problem.
If you temporarily remove the Location (Breadcrumbs) field, or the toolbar it's on, that may make things behave better while you're fixing the paths. It's one of the few things that can do (usually very quick, but not if a network server is unavailable and takes a long time to timeout) filesystem requests on the UI thread.
The quickest way to fix the paths in the config depends on what you've configured, really. If it was me, I'd just open a lister with just C:\ showing and create a new default lister from that. If you've got something more complex and need to keep different parts of it, it may be quicker to edit the XML files, or you might be able to do something via the Preferences UI, depending on what needs to be done.
The timeouts themselves are entirely down to Windows.
thanks for all your answers. I just tried to access an invalid path with Windows Explorer. No problem at all, sometimes the corresponding dialog pops up immediately, sometimes not and nothing happens. Compared with DO I can always change the path. In some cases DO is fading and shows the appropriate message in the title, and/or as mentioned is blocked for a long time.
Opening an lister with an active tab to an invalid path results to the same behaviour. I just waited more than four minutes until the lister was shown (two listers, with two "Empty" tabs are shown in the meantime). Trying to access a valid path with Windows Explorer during that time was successfull.
You can cause Explorer to have huge delays as well; I've seen them. Maybe not in the same places, but they happen.
(The long timeouts also always happen, it's just a question of what is waiting for them. We've moved most things that might hit such a delay to background threads, but there are still a few cases where we haven't, yet at least. The breadcrumbs location field I mentioned is one.)
I've used DO very happily since 2008. In fact I can't imagine ever changing to anything else. But recently I've been plagued with long delays of the type discussed here. In fact the exasperation of it is what drove me back to the forum. It seems to coincide with a change a month ago from 32-bit XP to a new machine running 64-bit Win 7 and an update of DO to 10.5.4.0. But it may just be a function of what I've been working on recently.
A really annoying scenario is where I have both panes open and with one or more tabs open to folders on a networked computer that's been shut down since the tabs were last viewed. For example, I've been working on files in identically named folders on the local and remote machine and the tabs aren't big enough to display enough text to tell me which tab belongs to which machine unless I click on them. But clicking on a 'dead' tab can make DO fade into grey and freeze for minutes on end.
It seems silly to have to kill the process. I'm wondering if there's a timer in Windows or DO, that I can edit to say 10s, instead of the several minutes that seem to apply at present?
There isn't a timer in Opus. There may be one deep in Windows, maybe in the registry, but I'm not sure. The suggestions Jon & I mentioned are your best bet for avoiding/reducing the problem.
(Remember you can also open a new window and leave the old one until it comes back to life. The delay should never affect the whole program, just the window that is waiting for a Windows API to timeout and return control to Opus.)
here my results of further investigating that problem:
[ul]
[li]Prevent loading...: no success[/li]
[li]Remove the Location (Breadcrumbs) field: not successful[/li]
[li]Updating my pathes: successful
I grepped my listers (*.oll files in folder C:\Users\User\AppData\Roaming\GPSoftware\Directory Opus\Layouts) with that awesome (commercial) tool - same league as Directory Opus : PowerGREP[/li][/ul]
Summarized I assume there is somewhere a problem in DO, especially as David stated there are other situations with that behaviour. And with Windows Explorer no problems at all.
Well, as Jon suggested, on Jan 15th I ticked boxes to Prevent Automatic Loading of Network Drives, but it hasn't changed anything. Although I referred to waits of 'minutes', it's usually 30 sec. But that's a big interruption to work-flow with a normally snappy system (SATA3 SSD). I've now ticked 'Drives that are powered down' and Removable Devices' as well to see what happens.