[PATCH 2/3] shell32: Make ShellView listen for filesystem changes
Nikolay Sivov
nsivov at codeweavers.com
Wed Jan 9 00:56:29 CST 2019
On 1/9/19 9:33 AM, Nigel Baillie wrote:
> On Wed, Jan 9, 2019 at 12:02 AM, Nikolay Sivov
> <nsivov at 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.
That's different case though, it shows that it does not match between
path pidl and special folder pidl, when special folder is actual
filesystem folder.
The issue as I understand is that unixfs is notifying with unix path
pidl, while registration was done for windows path. Is it possible to
make unixfs notify with windows path pidls instead? I don't know what
could possibly break because of that, it needs some testing. Also it's
possible to use a number of different flags during registration, no idea
what that affects results, but testing that could be helpful too.
>
> 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.
>
I think it's better, because it does not rely on kind of folder you're
viewing. I definitely remember testing application that was using
default shellview implementation with custom shellfolder instances
managed by application itself. Testing custom case like that could also
answer the question about how notifications are delivered, which is
appropriate to use at shellview side, etc.
More information about the wine-devel
mailing list