On 1/9/19 4:52 AM, Nigel Baillie wrote:
There was an issue where "new folder" operations didn't show the new folder when performed in certain locations. That issue was caused by a work-around for a another issue where pasting files in certain locations wouldn't show up until a refresh. The reason for those two issues stem from the fact that SHChangeNotifyRegister and SHChangeNotify operate on PIDLs, and there can be multiple PIDLs for a single path. |My Computer|C:|users| and |/|home|users| for instance.
Here we make shell views listen for external changes to their current location (if there's actually a filesystem path associated with it) by spinning up a thread that waits on FindFirstChangeNotification. When a change notification comes in, a message is posted to tell the shell view to update its list view (without re-sorting the list so as to not confuse the user too much -- similar to how Windows does it). As a result, SHChangeNotify is no longer necessary to get ShellViews to update their contents when files change.
I think it's conceptually wrong to rely on file paths here, because ShellView should be oblivious to the nature of underlying shell folder.
You mentioned unix vs windows path pidls being the issue here, could this be addressed instead, to provide consistent change notifications?