Closed Network Location Causes Delay
Posted: 19.02.2014, 16:48
Salvete! It's been awhile since I've visited the forum! Thanks for all the hard work, Marek!
FreeCommander XE 642 win32 on Windows7 pro x64
Say you've opened a few tabs:
\\device1\c$\somefolder
\\device1\c$\otherfolder
Then you turn off that device and are working in another program.
When you return to FreeCommander everything is fine until you try to close one of the tabs to the now-non-existant file share. It takes a whole minute for FC to realize the location doesn't exist - then after you click OK in the box that tells you the location doesn't exist, it takes another long amount of time.
Now it wouldn't be so bad to wait, but the entire FC window turns white with a waiting cursor and you are completely blocked out of doing anything in FC until the issue resolves.
Then you have to wait a second time for FC to resolve the second tab - albeit it isn't as slow, but the screen still freezes.
Network options:
Use FreeCommander for network loading = true
Show hidden shares = true
Use cache for server list = true
load network in background process on program start = true
[edit]
Same issue in version 653 x86.
I had a tab opened to a network location via administrator share.
I disconnected the device and when I returned about an hour later and clicked over to FreeCommander, the window froze up and turned white and froze that way.
It seems that FC does not make good use of separate threads to sort out network path resolutions.
I have waited now for two minutes and have to kill the FC process. Alas!
Can we keep FC from freezing up like that? Maybe at least pushing ESC could cause it to abandon it's attempt to resolve the process?
FreeCommander XE 642 win32 on Windows7 pro x64
Say you've opened a few tabs:
\\device1\c$\somefolder
\\device1\c$\otherfolder
Then you turn off that device and are working in another program.
When you return to FreeCommander everything is fine until you try to close one of the tabs to the now-non-existant file share. It takes a whole minute for FC to realize the location doesn't exist - then after you click OK in the box that tells you the location doesn't exist, it takes another long amount of time.
Now it wouldn't be so bad to wait, but the entire FC window turns white with a waiting cursor and you are completely blocked out of doing anything in FC until the issue resolves.
Then you have to wait a second time for FC to resolve the second tab - albeit it isn't as slow, but the screen still freezes.
Network options:
Use FreeCommander for network loading = true
Show hidden shares = true
Use cache for server list = true
load network in background process on program start = true
[edit]
Same issue in version 653 x86.
I had a tab opened to a network location via administrator share.
I disconnected the device and when I returned about an hour later and clicked over to FreeCommander, the window froze up and turned white and froze that way.
It seems that FC does not make good use of separate threads to sort out network path resolutions.
I have waited now for two minutes and have to kill the FC process. Alas!
Can we keep FC from freezing up like that? Maybe at least pushing ESC could cause it to abandon it's attempt to resolve the process?