8221852: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time

[Brian Burkhalter]

> On Apr 5, 2019, at 7:22 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> Unfortunately the build number is not stored at either the Java or native level. There appear to be at least four approaches to solve the problem.
> I met Robert Scholte (Maven) at FOSDEM and one of the things be brought up is that Maven are looking for additional OS version info to put into the mvn -version output [1].

In [1] the example output of ‘mvn -version’ is 10.0.16299.904. If I run ‘ver’ in ‘cmd’ in my Windows 7 VM I get 6.1.7601 which I know to be majorVersion.minorVersion.buildNumber. I don’t know what “904” in the example from [1] represents.

> Your #1 solution adds a os.buildNumber property and maybe an alternative to look at is existing os.version to add another element. It's hard to know how robust existing code that parses the value is so there may be compatibility impact to extending it beyond two elements.

That’s why I did not add it to os.version. Another alternative would be to add something like os.fullVersion instead of os.buildNumber. This might be useful on other operating systems as well.

> In any case, the original intention for WindowsNativeDispatcher was that the native methods map as close as possible to one win32 call so that the native code is as minimal as possible.

I know.

> Once Panama is further along then it should make it straight forward to migrate that code.
> 
> As regards the approach then WindowsFileSystem is the place where OS versions/features are probed. If you dust off a jdk8 clone then you'll see where it enables sym links and enumeration of data streams based on the OS version. That code was removed when support for running on ancient releases of Windows was dropped but it should give you ideas on where the OS version check should be.
> 
> I have no objection to your #4, at least temporarily until you've found a good approach.

My inclination is to roll back the code to its state prior to [2]. This could be done under the current issue 8221852 or a new issue. Work on another approach can proceed then as time permits.

> As it stands then it's problematic to have it set in the native method as it fail on some versions of Windows

I don’t see why but we don’t want it in the WindowsNativeDispatcher code anyway.

Note that the change to WindowsConstants in my option 2 of the previous message was inadvertent and not required.

Thanks,

Brian

> [1] https://issues.apache.org/jira/browse/MNG-6587 <https://issues.apache.org/jira/browse/MNG-6587>
[2] http://hg.openjdk.java.net/jdk/jdk/rev/66185e52b979
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190405/6b6f60ef/attachment-0001.html>