RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures (original) (raw)

Stuart Marks stuart.marks at oracle.com
Thu Jan 10 19:09:11 UTC 2013

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

More information about the core-libs-dev mailing list