On 2020-06-16 15:53, Jonathan Gibbons wrote:
It would also be good to identify the tests that are using temporary
directories in this manner and have them use the jtreg scratch
directory where possible.
I completely agree that tests should be fixed to behave better. Using
scratch instead of tmp is (almost) always a much better idea.
This workaround is needed to solve the immediate problem of certain
classes of machines in our test farm filling up small disks very fast.
/Erik
-- Jon
On 6/16/20 12:22 PM, Erik Joelsson wrote:
(re-sending this as it doesn't look like it was delivered)
There are a lot of jtreg tests that use temporary files. These
temporary files add up over time and fill up the global temp
directories on our test systems. To tackle this, we should try to
redirect these temporary files into a directory controlled by the
test framework. Jtreg does not do this, but we can set
-Djava.io.tmpdir from RunTest.gmk. This will not prevent all temp
files from being created outside of the work dir, but at least most.
I have found one test where this becomes an issue,
java/nio/file/Path/Misc.java on Windows when running in elevated mode
with the workspace on a subst drive. This looks like an actual issue
in the product, so I have filed a separate bug for it [1]. Since we
currently use subst in our distributed test system to get around
Windows path length issues, we are hitting this problem. While the
bug is being evaluated, I have implemented a workaround in the test
so that it is able to handle the known situation. I would like to
have someone from core-libs look at the workaround.
Webrev: http://cr.openjdk.java.net/~erikj/8213214/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8213214
/Erik
[1] https://bugs.openjdk.java.net/browse/JDK-8213216