On 08/29/2013 12:20 AM, Alan Bateman wrote:
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.
I tried to run this test on all platforms by removing L61. But it fails
on the second while loop on Solaris and Mac platforms. The reason is
that the testing path, which contains 20-level directory, is too long
for them to handle. That is why I added a new comment in L60.
I agree that we need a clean testing environment. David DeHaven found
"Application Experience" service interference at the end of last year,
but unfortunately that service cannot be stopped in Windows. And I am
also wondering whether we need clarify the Windows special behaviour in
our spec for the file/directory delete methods. For example, in
File.delete(), it currently says,
1019 * @return <code>true</code> if and only if the file or
directory is
1020 * successfully deleted; <code>false</code> otherwise
Thanks!
-Dan
