>>> It's a Windows feature. We discovered this recently in debugging another >>> test failure. Windows is documented to do asynchronous deletes. You can't >>> depend on a file.delete() which returns true to have actually deleted the >>> file. It may be the case that another process has a file handle which it >>> has >>> not yet released, or it's simply a delay. >> I don't get this, the issue sounds more like AV software or Windows >> application >> quality service/agent thing accessing the file but I might be wrong of >> course. >> Are you able to duplicate this reliably and if so, have you looked at it with >> any tools to see what/who is accessing it that is causing the delay? > > Dave DeHaven was able to reproduce this in his diagnosis of the Arrrghs test > failure.
That was a fun one to track down... > << The DeleteFile function marks a file for deletion on close. Therefore, the > file deletion does not occur until the last handle to the file is closed. > Subsequent calls to CreateFile to open the file fail with > ERROR_ACCESS_DENIED. >> > > (I'm not a Windows developer, so I may be looking in the wrong place or > misinterpreting something. Please correct me if I'm wrong.) No, you have it :) The call to DeleteFile does not actually *delete* the file, it simply marks it for deletion at some point in the future. > If the AE daemon has the file open the moment the test deletes it, the file > will remain present until the AE daemon has closed it. > > This seems built into Windows. I think we have to live with it. Presumably > these various daemons open the file with CreateFile(FILE_SHARE_DELETE) [2] > allowing the "owner" of the file to delete it (eventually). Note this also > allows renaming of the file. So the rename-before-delete technique seems like > the most promising approach. I concur. -DrD-
