On 29/08/2013 00:49, Dan Xu wrote:
:
Stuart brought a very good point for this test failure in the main
bug, JDK-7160013. According to his comment, "Bottom line is that a
Windows daemon (not an anti-virus scanner) may hold a file in
delete-pending state for a short amount of time after it's been
deleted. While it's in this state, if you ask if the file exists, the
system will say that it does not. However, if you try to create a new
file with the same name, you get an access denied error."
And I re-checked remarks in the Windows APIs used for deleting file in
[1] and directory in [2]. According to the spec, these APIs only mark
a file/directory for deletion on close. And the delete operation does
not occur until the last handle to it is closed. Therefore, if a
Windows daemon opens a handle towards those newly-created directories
(I think anti-virus on-access scanner may do a similar thing), the
delete operation will be put in delete-pending state, and the next
immediate call to create the same directory structure will fail.
Based on the above information, I updated this testcase to make it
create different directory structure in each loop, so that the
next-create operation will not conflict with previous pending delete
operation. I also follow Alan's suggestion to use Files.deleteIfExists
in the latest change. Please review it at
http://cr.openjdk.java.net/~dxu/8023765/webrev.01/. Thanks!
If we want stable and fast test execution on Windows machines then I
think we have to remove these sources of interference. In my view this
means disabling the services that snoop on your usage so that they
aren't opening files that are trying to move or remove. It also means
configuring the AV software to exclude some area of the file system that
we can use as the test work tree.
Anyway, the patch looks okay, it's just the new comment on L60 might be
a bit mis-leading.
-Alan.
