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

[David DeHaven]

>>> 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-