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.
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.
+/************************************************************************
- 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!
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. And like I mentioned above not all SHChangeNorify where sending correct notifications either.
I believe there are some issues with this patch as it hasn't been applied yet to Wine. One of them could be that it is considered to be to much changes at once. Maybe somebody could comment on what might be the problem with that patch.
Rolf Kalbermatter
Vitaliy Margolen