On 08/27/2013 07:15 AM, Dan Xu wrote:
On 08/27/2013 12:12 AM, Alan Bateman wrote:
On 27/08/2013 01:18, Dan Xu wrote:
Hi All,
MaxPathLength.javais a troublesome testcase, and fails
intermittently in the nightly test. And it also runs for a long
time, especially on Windows platforms. Inorder to improve the test
stability, I remove its unnecessary test iterations, and use
NIOdelete method todo the clean-up to make the potential
failureseasier for diagnosis. Please review thechanges. Thanks!
bug: https://bugs.openjdk.java.net/browse/JDK-8023765
webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/
-Dan
The double to quickly skip over the names to MAX_LENGTH/2 looks
reasonable.
I guess fileCreated should really be fileExists as it may be deleted
and then deleted. An alternative here would be to use
Files.deleteIfExists as that would avoid the need to introduce flags
to track whether the directory and exist exists.
-Alan
Hi Alan,
Those flag names are a little misleading. Sorry about that.
fileCreated and dirCreated are actually tracking the existence of new
file and directories. If the new file gets deleted, I marked the flag
to false in the code. And at the end, I also change the recorded file
path after the rename operation.
I agree that using deleteIfExists is a good alternative. In my
original thought, I plan to monitor every step and make sure all file
operations happen as expected. Thanks!
-Dan
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!
-Dan
[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/aa365488%28v=vs.85%29.aspx
