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

Alan Bateman Alan.Bateman at oracle.com
Thu Aug 29 07:20:53 UTC 2013

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.


More information about the core-libs-dev mailing list