On Wed, Jan 9, 2019 at 12:02 AM, Nikolay Sivov nsivov@codeweavers.com wrote:
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?
I see what you're saying.
When I started tackling this, my first instinct actually was to just make SHChangeNotify and SHChangeNotifyRegister "normalize" all incoming pidls into unix-style pidls whenever possible. I wrote a test that calls SHChangeNotifyRegister on |C:|Users|whatever|My Documents|, then calls SHChangeNotify on the special |My Documents| pidl (from SHGetFolderLocation), but it actually didn't work on Windows. My Windows 10 install, at least, didn't receive notifications when SHChangeNotify and SHChangeNotifyRegister were called with pidls with different-but-equivalent paths.
Do you think that's a better solution, though? I can submit that as a patch, too if you'd like. It still somewhat relies on file paths because (do correct me if wrong!) the only way to turn a non-unix-style pidl into a unix-style pidl is to turn it into a file path, then back into a pidl. I decided to go with this FindFirstChangeNotification solution because it doesn't break compatibility (I dunno how crucial SHChangeNotify compatibility is) and has the added benefit of making file browsers respond to external changes just like most native file browsers.