SHFileOperation - add ChangeNotify events

[Vitaliy Margolen]

Tuesday, March 11, 2003, 11:42:09 AM, Rolf Kalbermatter wrote:

> Hi,

>> The main reason why I made this patch is to make our software package work under
>> WINE. Our application was heavily relies on correct behavior of SHFileOperation
>> function. In particular:
>> 1. User confirmation for deleting files and folders.
>> 2. Ability to delete files only in any given directory.
>> 3. Receiving notifications for every operation to refresh screens properly.

> I'm going to check those things. I know that file movements did not implement
> SHChangeNotification, mainly because I wanted to check first that they really
> got genereated in Windows native.
I'm not sure here. I haven't tested it under windows. But logic suggests that it
will. Since all other operations from SHFileOperation do generate Notify events.

> Do you mean in 2) that the user can acknowledge every single directory to be
> deleted? Mmmh, thinking about it I see that Windows allows to select 4 different
> buttons to delete all, only this, this not or cancel. Well this is sort of
> involved but can be implemented.
in 2) I Meant use of flag FOF_FLILESINLY

>> Yes, I could hack that patch and make it work but I used existing code as a basis
>> since it implements _all_ functionality of SHFileOperation except unicode.
> That is not exactly true. The rename operation is not fully implemented in the current
> code as well as some of the operations with multiple file names.
Sorry my bad. I should of looked at the code closer.

Major missing parts was:
- No implementation for FOF_FLILESINLY
- Incorrect Notify events
- Improper handling of *? in some tests (don't remember which ones)

My point here is: I don't think Alexandre will apply this patch if it doesn't pass
all tests while current code does.


[skip]
>> So, after a file gets deleted it's path is no longer valid. What was happening is
>> application was getting notification that whole drive was deleted!

> Mmh, we have to investigate further in Windows. Because the Win32... functions itself
> in W2K do actually not take this precaution and appearently assume that SHChangeNotify
> does the proper action. So either W2K does something else somewhere or the Wine
> SHChangeNotify function is broken in that it should be able to create notifications
> even for just deleted directory and file paths. I guess the later as MSDN mentions
> nothing that the parameter needs to be an IDLIST instead of a path for those
> operations but rather explicitedly mentions that SHCNF_PATH is allowed for
> SHCNE_DELETE, SHCNE_RENAME, SHCNE_RMDIR and such.
Well it's hard to tell what _exactly_ going on inside native shell32.dll. :-)
There are number of thing which look different:
- Notification events happening about 1-2 seconds after operation is completed.
- There whole Explorer thingy running at all times. Who knows what it keeps in it's
  memory? :-)

When I said "This fact verified on windows." here is what I did: I tried to create
PIDL from non-existent file. In WINE we have same problem: delete first, create PIDL
and send to app _after successful_ operation. Unless we'll cache this operations on
low level and keep it's info around for some time - it will not work. In some way I
did exactly that - stored PIDL of file/directory that was about to be deleted/renamed.

If you want I can run few tests on Windows to see how it reacts on SHChangeNotify
call with a path of a deleted file.

[skip]
> I still intend to get the patch(es) to SHFileOperation applied if possible, but also
> want to make sure it doesn't break your application at all. Are you interested to get
> eventual new patches sent directly as they get verified?
Yes I would be very mach interested in testing these patches in my sand box.


Vitaliy Margolen