A customer had created a custom shell namespace, and they generated notifications for items in that namespace. Meanwhile, they also had code that listened for those notifications, and they found that sometimes the listener received SHCNE_ notifications, which is odd because their namespace never generates those notifications. So where did they come from?
The shell change notification system will sometimes coalesce notifications. It typically does this to avoid flooding the notification system.
The customer wanted to know if coalescing was more likely to happen when the notifications are generated at high frequency. They found that the behavior varied from system to system. Some of them were seeing the SHCNE_, and others weren’t.
Yes, the rate of notification generation is a factor. If you quickly generate a hundred SHCNE_ notifications for items all within the same folder, the shell change notification system is probably going to replace them all with a single SHCNE_ notification. The likelihood of coalescing also increases if the recipient is slow to process the notifications.
In such cases, the shell replaces the separate “item 1 changed”, “item 2 changed”, “item 3 changed” notifications with a single SHCNE_, which means “There were changes to this folder.” This reduces the amount of notification traffic, reduces the memory needed to keep track of those notifications, and hopefully improves performance on the clients, since they can just refresh the whole folder instead of churning through hundreds of tiny little notifications.
When explorer.exe isn’t running as the taskbar shell, all shell namespace updates cease because the taskbar unnecessarily hosts the relayer. I would rather get spammed than have nothing at all. Every file manager window just sits there without the updates, unless we wire up ReadDirectoryChangesW and a bunch of other functions too but then we’re just recreating the namespace.