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:
- User confirmation for deleting files and folders.
- Ability to delete files only in any given directory.
- 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