RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Erik Joelsson]

On 2020-06-17 01:24, Alan Bateman wrote:
> On 16/06/2020 18:44, Erik Joelsson wrote:
>> 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
> subst is a legacy mechanism. We know from previous attempts to 
> reconcile usage of subset with NTFS symbolic links creates surprises 
> and inconsistencies. I don't object to putting a workaround in the 
> test but I think more information is required, in particular the 
> comment that 'file' is guaranteed to be subst free? Can you expand on 
> this? Some examples would be useful as it's not clear how subst is 
> used in the environment, is it solely that java.io.tmpdir is set to 
> something like S:\tmp and S: is mapped to some other location?
>
The following code breaks if file refers to a path on a subst drive.

Path file = Files.createFile(dir.resolve("foo"));
Path link = dir.resolve("link");
Files.createSymbolicLink(link, file.toAbsolutePath());
assertTrue(link.toRealPath(NOFOLLOW_LINKS).getFileName().equals(link.getFileName()));

In our case, this is caused by having a workspace in d:/X/Y/Z/workspace 
and having run something like "subst t: d:/X/Y/Z" before invoking the 
"make test" command in "t:/workspace". We currently need that subst to 
shorten path lengths because the X/Y/Z is a very deep path outside of 
our control. (We are looking into other solutions to this, but may not 
be able to apply them universally) Currently java.io.tmpdir is pointing 
to the default location, so the test passes, but if I explicitly set 
java.io.tmpdir to point into a subdir of the workspace (which is what 
this patch is about), then we trigger this failure.

I have stepped through the various variants of calls to 
Path::toRealPath. When called on a path to a normal file, with no 
symlinks in it, it will resolve the real path with pure java string 
manipulation. When called on "link" above, the java loop detects that 
there is a symlink and defers to a native Windows API to resolve the 
symlink. This is done by getting a handle to the link, then resolving by 
handle. The file path returned from that call has the subst resolved.

I don't know of another way to explicitly resolve subst drives back to 
their original directory from Java, so the workaround I put in place 
here simply does the same thing as the actual test. I create a link to 
"dir" and call toRealPath on it. If dir was located on a subst drive, 
then the return value from that call is guaranteed to have resolved that 
subst back to the original location.

I've tried to make this clearer in the comment.

http://cr.openjdk.java.net/~erikj/8213214/webrev.02/

/Erik