Notepad++ not responding state when network file is disconnected

[dmelnik92]

Description of the Issue

Notepad++ not responding state when network file is opened and the network location is no longer available

Steps to Reproduce the Issue

1. Open a network located file in notepad++
2. Disconnect the network drive or lose connectivity to the network location
3. Open notepad again or make the window active

Expected Behavior

A notification that the network drive is no longer available. A faster response.

Actual Behavior

Notepad++ went to not responding state.

Debug Information

[m0m4x]

This issue creates lots of suffering if you work lots on different enviroments.. Please Fix it... Thank you!

[sukhoi191]

Until there is a fix, a quick workaround is to delete %APPDATA%/Notepad++/session.xml. However, this will also delete all the information regarding any other files that were open in other tabs. To prevent that, you might edit session.xml instead of deleting it and remove only problematic "File" elements with paths leading to disconnected network drive.

After quick analysis, Microsoft's PathFileExists defined in "Shlwapi.h" fails in this specific case. Program hangs on the first PathFileExists call in Notepad_plus::loadSession. This function is used in lots of places throughout the code. I guess changing it in a single place and leaving other calls intact is not a good idea, so fixing it would require modifying multiple files.

Here's a link to my Microsoft's report: https://aka.ms/AAgz0ej

It seems this function relies heavily on how Windows handles network drives. When you use Windows file explorer and try to open a network drive shortly after it's disconnected, explorer itself will freeze for some time. Eventually, when it fails and there is an error message displayed, explorer and this function both start to work correctly. I don't think Microsoft is going to change it, so maybe we should use some other function, instead of PathFileExists?

Similar issues: #11388, #6178.

[soutzis]

Came here to open this exact issue. I can confirm that this is also happening for version 8.6.2.
If there could be some sort of "timeout" when opening inaccessible files, or if the function that checks if the file can be opened could be replaced with a different one that handles the error gracefully, then it would be very much appreciated.

[xomx]

possible workarounds:
#12553 (comment)
#12553 (comment)

@sukhoi191

we should use some other function, instead of PathFileExists?

I am wondering if a simple replacement by a WIN32 equivalent (e.g. GetFileAttributes, FindFirstFile, CreateFile ...) of that Windows shell SHLWAPI could help.

Personally, I am a bit skeptical that just that simple func swapping would work. Funcs like GetFileAttributes or PathFileExists are just synchronous, that's it. Even using of the asynchronous IO with the help of CreateFile & FILE_FLAG_OVERLAPPED cannot help (you can then use asynchronous ReadFile/WriteFile WINAPI IO on the file handle created by such CreateFile, but the CreateFile call itself is still synchronous!)

I have no simple and clean solution here, sorry.
What could be doable is to write a N++ specific IsFile() func, in pseudo-code (as a possible PathFileExists replacement, it should have the same return type and input params):

BOOL PathFileExistsNpp(filename2test)
{
    if (IsThisANetworkFile(filename2test)) //  our func to be written
    {
        if (! IsThatNetworkFileResourceAlive-AsyncPingOrSimilar(filename2test)) //  our func to be written
            return FALSE;
    }
    
    return PathFileExists(filename2test); // standard WINAPI
}