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
