Disconnected UNC paths spawn countless error messages and crashdump program

[dgdomtar]

Describe the bug
I use E++ in an IT support environment and UNC path (Universal Naming Convention) to connect to a lot of computers to modify and transfer files. I frequently have multiple tabs open to multiple UNC paths.

In the newest builds, it seems that E++ keeps a "pulse" to those UNC paths. If any of those computers are disconnected/shut down/removed from the network, E++ starts freaking out and throwing error window alerts. Often times however, all of those errors won't show until it reaches a "breaking point" where countless of them will flood and take up the entire Start bar. Trying to close them eventually causes a crash and crashdump to happen.

I suggest to modify the connection to remove the 'pulse' checker and if it can't connect to a share, it will not alert until you try to refresh the connection, at which time a single connection error would occur.

To Reproduce
Steps to reproduce the behavior:

• UNC to a few computers in some tabs
• Disconnect or turn one of them off
• Let it sit for awhile (unfortunately I can't give a specific timeframe when or how this occurs)
• Eventually when you come back and try to start working it will error out.

Expected behavior
A single error message alerts that the connection was not found or doesn't take down the program.

Screenshots
If applicable, add screenshots to help explain your problem.

Version (please complete the following information):

• Explorer++ version 1.5.0.2528 dev (64-bit build)
  Build date: Nov 8 2024 17:36:51
• OS: W11 Ent 24H2 26100.2314

Additional context
Next time this happens I will try to get screenshots and some dumps if I can.

[derceg]

What's happening here is that multiple directory change notifications are sent when the folder is disconnected. One of those notifications (SHCNE_UPDATEDIR) indicates that the directory still exists, but its contents have changed in some way. That notification is very general and doesn't tell you what changed. Therefore, to handle it, Explorer++ will refresh the directory.

Because the directory no longer exists, a dialog will be shown when refreshing. While the dialog is being shown, Explorer++ will try to refresh the directory again (due to the dialog causing reentrancy), which will trigger another dialog and another attempt to refresh, etc. The fact that the refresh tasks are being processed in a reentrant way is bad, so that's something that needs to be fixed.

It might also be useful to check whether the current directory exists before attempting an implicit refresh. If it doesn't exist, Explorer++ could navigate up instead. Once Explorer++ navigates to a different folder, all current tasks are dropped, so any further queued refresh tasks would be ignored.

Long-term, it would probably also be better to update the directory in-place, rather than refreshing it when an SHCNE_UPDATEDIR notification is received. But that's not something that can be easily done right now.

[dgdomtar]

As a stop gap release, could it be modified to not log or throw errors / ignore it and not crash?