RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce its test load

[Dan Xu]

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