XY hangs when disconnecting dead network drives

[Mesh]

For a while now, XY hangs for several minutes when disconnecting (unmapping) a network drive that's no longer online.

I saw the change log notes regarding network resources and hoped that it would address this, but "Pre-check availability of servers" does not fix this. Is there some other setting that would address this?

If not, it would be nice if XY could handle this gracefully and quickly.

[admin]

You mean Tools | Tools Special | Disconnect Mapped Network Drive...? This code has not been changed for 5 years. And there is nothing to optimize here. It's a simple call to an API function.

BTW, why would you disconnect a dead drive in the first place? It should be already disconnected. Or what is the difference between dead and disconnected?

[Mesh]

A network share is periodically mapped to a drive letter. However, if the network share goes offline, certain actions in XY (such as a general refresh) causes XY to hang. If I unmap the drive letter while it's still up, it unmaps instantly. But if the share is down, unmapping causes XY to hang for several minutes.

If you're making an API call, then the problem is probably that Windows is taking a while before the unmap action times out. Compounding the issue is that I can't even open a new instance of XY to work in while the first one completes the disconnect. The new instance will open, but will shortly also hang, and neither of them frees up until the disconnect routine times out and completes.

Edit: To clarify, if you're browsing the Network tree object, then there's no difference between a network resource being dead and disconnected. But once you map it to a drive letter, that mapping is always there regardless of whether the network object is accessible or not.

[admin]

I see. So I guess a little pre-check would help here. I see whether I can add that...

[Mesh]

I see. So I guess a little pre-check would help here. I see whether I can add that...

Bless you!

[admin]

Checked it: Not possible. The API is not passed any path that I could pre-check. The API itself looks for any shared resources that could be disconnected. So there is nothing I could do.

[Mesh]

Is it possible to spawn a worker thread for the api call so that it doesn't cause XY to hang? Or will it hang any and all file managers until it's complete?

[admin]

I still don't really understand the issue. When you click Tools | Tools Special | Disconnect Mapped Network Drive... you get a window that shows all mapped drives. Then you choose the one you want to disconnect (see image). At which point does it hang? (It's always totally instantaneous here.)

[Mesh]

Okay, so let's say that you're mapping a shared folder on another machine. You map this shared folder to a drive letter. While the second machine is on, you can disconnect the drive at any time, and it will occur instantly.

However, if you turn off that second machine first, you'll still have your mapped drive - but it's targeting a dead resource. So if you go to where your screenshot is, select the drive letter in question and then click OK, that's when XY will hang for a couple of minutes.

[admin]

What happens if you do the same thing in Explorer?

[Mesh]

I'll have to test it out, but I expect it will be the same, given that it's an API call. However, I also don't expect Explorer to optimize anything.

So to go back to my earlier question, do you think this is something that will lend itself to running gracefully in a worker thread? Or do you feel it's going to block any file manager until it's done regardless of threading?

[admin]

From the documentation it seems to work asynchronously by itself: https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

[Mesh]

How very odd, because that certainly doesn't describe what I see. When I try to disconnect a dead network drive, XY is completely non-responsive. About 10-20 seconds in, the disconnect dialog box pops out into its own taskbar object, but both it and XY are still nonresponsive.

I have no choice but to leave them both be and eventually, when the dialog box dissappears from the taskbar, I know that it's finished and XY is finally responsive again.

If that's running in a worker thread already, then there is something further into the backend that isn't being optimized the way it should be. In which case, your hands are almost definitely tied.

That's unfortunate.