RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures

[Stuart Marks]

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