RFR (M) 8191521: handle long relative path specified in -Xbootclasspath/a on windows

David Holmes david.holmes at oracle.com
Tue Jul 23 03:59:29 UTC 2019

Hi Ralf,

I think this issue is struggling to find hotspot developers with indepth 
familiarity with Windows UNC paths - sorry. It's not something I know 
much about. We try to use equivalent JDK code for guidance here as those 
folk have more familiarity with this. So does this problem exist in the 
JDK as well or is it unique to hotspot?


On 4/07/2019 8:56 pm, Schmelter, Ralf wrote:
> Hi,
> can you please review this patch to fix various long path related problems in the hotspot os code on Windows.
> As described in the bug the current code cannot handle relative paths in these cases:
>    1.  If the relative path is < 260 chars, but the absolute path is > 260 chars. In this case if the I/O method uses the *A variant of the system call as an optimization, it will fail.
>    2.  If the relative path is > 260 chars or the I/O method always uses the *W variant. In this case the create_unc_path() method is called, which just prepends \\?\ to the relative path. But this is not a valid path to use and the system call will fail.
> Additionally there are problems with some other kinds of paths:
>    1.  An absolute path which contains '.' or '..' parts and is > 260 chars or the I/O method always uses the *W variant. When given to the create_unc_path() method, it will just prepend \\?\. But this is not a valid path to use and the system call will fail.
>    2.  An UNC path which is > 260 or the I/O method always uses the *W variant. The create_unc_path erroneously converts \\host\path to \\?\UNC\\host\path<file://%3f/UNC/host/path> (notice the double backslash before the host name). This again is not a valid path. Additionally '.' or '..' parts would not be handled correctly too.
> To fix this I've introduced a new function, which converts a path to a wide character unc path, calling _wfullpath() to make the path absolute if needed and to remove the '.' and '..' path parts. I've adjusted all methods which used create_unc_path() to use the new method. And I removed all fallback code using the ANSI variants, since benchmarking showed that on my machine the additional overhead of converting to a wchar and potentially calling _wfullpath() was less than 5% of the actual I/O routine called. And for this reason, why I haven't tried to optimize avoiding calls to _wfullpath() (e.g. checking for '.' and '..' and only calling it if we find this in the path).
> bugreport: https://bugs.openjdk.java.net/browse/JDK-8191521
> webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8191521/webrev.0/
> Best regards,
> Ralf

More information about the hotspot-runtime-dev mailing list