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

[Dan Xu]

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