RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce its test load
dan.xu at oracle.com
Wed Aug 28 23:49:36 UTC 2013
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/
>> The double to quickly skip over the names to MAX_LENGTH/2 looks
>> 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.
> 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!
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
 and directory in . 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
More information about the core-libs-dev