[PATCH 0/3] Add more winsymlinks values

[Jon Turney]

On 22/07/2021 15:21, Corinna Vinschen wrote:
> On Jul 22 14:53, Jon Turney wrote:
>> On 21/07/2021 09:19, Corinna Vinschen wrote:
>>> On Jul 19 17:31, Jon Turney wrote:
>>>> I'm not sure this is the best idea, since it adds more configurations that
>>>> aren't going to get tested often, but the idea is that this would enable
>>>> proper and consistent control of the symlink type used from setup, as
>>>> discussed in [1].
>>>>
>>>> [1] https://cygwin.com/pipermail/cygwin-apps/2021-May/041327.html
>>>
>>> Why isn't it sufficient to use 'winsymlinks:native' from setup?
>>
>> I think in the default Windows configuration (developer mode off, no
>> SeCreateSymbolicLinkPrivilege), 'native' will try to create a native symlink
>> and fail, and fallback to WSL IO_REPARSE_TAG_LX_SYMLINK reparse point, then
>> magic cookie + sys attribute.
>>
>> This leads to cygwin installations with WSL symlinks created by post-install
>> scripts, which can't be put into Docker containers [1], which is the
>> original problem I was trying to fix.
>>
>> [1] https://cygwin.com/pipermail/cygwin/2020-August/245994.html
> 
> Did nobody ask the Docker guys why they fail to support perfectly
> valid reparse points?

It seems so e.g. [1]. The answer isn't much beyond "yes, that doesn't 
work", though.

[1] https://github.com/moby/moby/issues/41058#issuecomment-692968944

>> I haven't yet looked at adding 'native' symlink support to setup itself, but
>> it's probably going to be a bit of a pain.
> 
> That may be not a bad idea after all.  Setup typically runs as elevated
> process, so it has the required permissions to create native symlinks.
> Scripts could then run with CYGWIN=winsymlinks:native by default.
> 
> As long as nobody has the hare-brained idea to move a Cygwin distro
> manually, native symlinks should be just as well as Cygwin symlinks.

I'm pretty reluctant to add this to setup in any form which isn't 
initially  "keep doing what we currently do, unless you explicitly ask 
for symlinks to be made a different way".  (especially since when we 
changed what we were doing in Cygwin 3.1.5, it opened this whole can of 
worms)

So I don't think that gets us any further forward if setup doesn't have 
useful control over the kinds of symlinks made by post-install scripts.

>>> The way we express symlinks shouldn't be a user choice, really.  The
>>> winsymlinks thingy was only ever introduced in a desperate attempt to
>>> improve access to symlinks from native tools, and I still don't see a
>>> way around that.  But either way, what's the advantage in allowing the
>>> user complete control over the type, even if the type is only useful in
>>> Cygwin?
 >>
>> If we can come up with a fixed policy that works everywhere, there is no
>> advantage.  But that seems unlikely :)
>>
>> I could buy an argument that 'native' should be the default (although maybe
>> all that does is slow things down in the majority of installs?).
> 
> It may slow down installations a tiny little bit because the target
> paths have to be converted to POSIX, but I doubt this is more than just
> a marginal slowdown.

My assumption was that "the majority of installs" are running where 
native symlink creation isn't permitted, so the slowdown I meant was 
that adds "try to create a native symlink, fail and fallback" for every 
symlink creation.