JDK-8221852 : SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 13
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2019-04-02
  • Updated: 2019-04-16
  • Resolved: 2019-04-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b16Fixed
Related Reports
Relates :  
JDK-8221824 - Build failure with MSVS 2013 after JDK-8218418
Description
The changes in JDK-8221824 were a short term fix to get the build working on an old SDK release that didn't define SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE. The fix is not the right solution as it will not set the flag when run on Windows 10. This issue tracks re-visiting this so that the flag is set when running on Windows 10 or latter, irrespective of the build platform.
Comments
In terms of implementation, this flag needs to be moved to WindowsConstants.java. It's okay for WindowsNativeDispatcher.CreateSymbolicLink to add the flag when on platforms that support.
03-04-2019
There could be a more complicated problem here which is that the flag might not be available for all Windows variants with major version >= 10 (currently Windows 10, Windows Server 2016, and Windows Server 2019). According to https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#DXz6icKZOkEozgYR.97 the ability to create links without elevating the console to administrator was added in "Windows 10 Insiders" build 14972. So it appears that in addition to a major version check a build number check might be required. This is corroborated by https://cygwin.com/ml/cygwin/2017-04/msg00305.html If the foregoing build number 14972 corresponds to the "OS build" such as given at https://docs.microsoft.com/en-us/windows/windows-10/release-information then that would imply that that the Windows release ID would be 1703. Testing on a Windows Server 2016 machine with release ID 1607 and OS build 14393.2189 corroborates the foregoing as running the same test which succeeded on Windows 10 in testing the patch for JDK-8218418 failed with the error: Exception in thread "main" java.nio.file.FileSystemException: link: The parameter is incorrect. at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.createSymbolicLink(WindowsFileSystemProvider.java:582) at java.base/java.nio.file.Files.createSymbolicLink(Files.java:1061) at CreateLink.main(CreateLink.java:12) The first Windows release ID which includes build number 14972 is 1703, the release ID just after 1607. So it appears that either of the following run time checks would be needed: A) buildNumber >= 14972 or B) releaseId >= 1703. Unfortunately there appear not to be any straightforward ways to come by either the build number or release ID aside from accessing the registry which does not seem like a great idea. (The build number is loaded in native code during property initialization but not stored.)
02-04-2019
Interestingly, on Windows 7, the same test fails with Exception in thread "main" java.nio.file.FileSystemException: link: A required privilege is not held by the client. at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.createSymbolicLink(WindowsFileSystemProvider.java:582) at java.base/java.nio.file.Files.createSymbolicLink(Files.java:1061) so one could infer that it is doing an access control check before validating the function parameters.
02-04-2019