On 1/10/13 3:34 AM, Alan Bateman wrote:
On 09/01/2013 19:46, Jim Gish wrote:
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.
It's a race condition, because the Windows Application Experience daemon opens
up files with certain extensions (.bat, .cmd ?). I suspect it gets a filesystem
notification that a file matching the right pattern has been created, so some
time later it gets around to opening the file; and then after processing it, it
closes the file.
That a file remains in the filesystem after having been "deleted" indeed is
documented Windows behavior. The doc for the DeleteFile function [1] says,
<< 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.)
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.
s'marks
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915%28v=vs.85%29.aspx
[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
