SHFileOperation - add ChangeNotify events

[Rolf Kalbermatter]

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.

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 the patch from 2/20/2003 only (1) was implemented properly.
> 
> 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.
 
> >>+/************************************************************************
> >>+ * Win32DeleteFile                         [SHELL32.164]
> >>+ *
> >>+ * Deletes a file. Also triggers a change notify if one exists.
> >>+ *
> >>+ * NOTES:
> >>+ *  Verified on Win98 / IE 5 (SHELL32 4.72, March 1999 build) to be ANSI.
> >>+ *  This is Unicode on NT/2000
> >>+ */
> >>+static BOOL Win32DeleteFileA(LPCSTR fName)
> >>+{
> >>+       LPITEMIDLIST    Pidls[1];
> >>+       DWORD           dummy;
> >>+
> >>+       TRACE("%p(%s)\n", fName, fName);
> >>+
> >>+        SHILCreateFromPathA(fName, &Pidls[0], &dummy);
> >>+       DeleteFileA(fName);
> >>+       SHChangeNotify(SHCNE_DELETE, SHCNF_IDLIST, Pidls[0], NULL);
> >>+        SHFree(Pidls[0]);
> >>+       return TRUE;
> >>+}
> > The addition of SHILCreateFromPathA/W to all of these functions is superfluous
> > since SHChangeNotify does this for you anyhow if you pass in a normal string
> > path. So your patch adds in this respect nothing besides of duplicating already
> > existing code.

> Not in the placed I used this function. It is impossible to create PIDL from non-existing
> path. This fact verified on windows. Whenever I tried to create PIDL of deleted file,
> Windows was returning error. This means we have to get PIDL _before_ removing file.
> Same goes for renaming files.
> 
> 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.

> > Also please note that there is another patch to SHFileOperation from 2/20/2003
> > pending which reimplements this function from scratch up with a different
> > algorithme, which implements all of the operations and is quite thorougly
> > verified to behave in all major aspects exactly like the Windows 98/2000
> > version of this function, which one can't fully say of the current function
> > in Wine. It happens to use internally also additionally implemented functions
> > which also set the according SHChangeNorify in most places.
>
> I tried using that patch before doing any hacking on my own. It fails at least half
> of the conformance tests. I tried to fix few things with that patch but some will
> require significant changes. And I didn't want to go that far - working on a patch
> which is not even applied.

I'm going at the moment through these tests and am also trying to add more tests as
well, just need to get my development machine reinstalled first after a HD crash.

The tests done before where not the conformation tests but some rather involved
tests with multiple shell scripts doing all types of tests for the different file
operations. They did indeed not test the user dialogs at all (as they were designed
to be unattended tests to run and also the SHChangeNotifiers were not tested either
as I wanted to find out first if they were actually done at all.

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?

Rolf Kalbermatter