public inbox for
 help / color / mirror / Atom feed
From: Jon Turney <>
To: Cygwin Patches <>
Subject: Re: [PATCH 0/3] Add more winsymlinks values
Date: Wed, 28 Jul 2021 20:55:33 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YPl+7gROlATG/>

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]
>>> 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]
> 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.


>> 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 

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.

  reply	other threads:[~2021-07-28 19:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 16:31 Jon Turney
2021-07-19 16:31 ` [PATCH 1/3] Rename WSYM_sysfile to WSM_default Jon Turney
2021-07-19 16:31 ` [PATCH 2/3] Add winsymlinks:magic Jon Turney
2021-07-19 16:31 ` [PATCH 3/3] Add winsymlinks:wslstrict Jon Turney
2021-07-21  8:19 ` [PATCH 0/3] Add more winsymlinks values Corinna Vinschen
2021-07-21 10:24   ` Christian Franke
2021-07-22  8:03     ` Corinna Vinschen
2021-07-22 13:53   ` Jon Turney
2021-07-22 14:21     ` Corinna Vinschen
2021-07-28 19:55       ` Jon Turney [this message]
2021-07-29 10:23         ` Corinna Vinschen
2021-07-29 10:40           ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).