RFR: CODETOOLS-7902418: jtreg fails to guarantee a cleaned scratch directory sometimes on windows and CODETOOLS-7901369: jtreg should be able to clean up read-only files under result dir

[Langer, Christoph]

Hi,

here’s the fix that I actually wanted to build/test when I saw the Cygwin issue…

In our CI test infrastructure, we use jtreg in agentvm mode to run tests in parallel. On Windows we regularly see an issue that bubbles up because the 2 tests:
jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java
jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java
are run one after another in the same agent vm, hence in the same scratch directory.

The issue boils down to the Windows DeleteFileW API which is used under the covers of java.io.File::delete. It does not always guarantee an instantaneous deletion of a file. When there are handles open to a file, it'll set a delete on close flag and defer deletion to a point when the last open handle is closed.

The problematic behavior in the tests is that the first test (RunWithAutomaticModules.java) would create a jar file to be used on the module path. Due to some compilation operation, I think the process keeps the handle to the jar file open. When the next test (OverlappingPackagesTest.java) is run (in the same VM that still holds the open file handle), jtreg empties the scratch directory and thinks it is successful. But then the test stumbles over the zombie file which is still there and cannot be accessed.

Jtreg can be improved to check if a file was really deleted after the call to File::delete.

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/CODETOOLS-7902418.0/
Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902418

I verified that this will fix the issue that we observe. I’d think that the performance overhead for an additional call to File::exists is neglectable.

This would also resolve this bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901369 which is possible now as https://bugs.openjdk.java.net/browse/CODETOOLS-7901611 has been resolved, updating the jtreg baseline to JDK 1.7.

If you like the fix, I would also need a sponsor ��

Thanks & Best regards
Christoph