March 12, 2003
5:21 a.m.
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