[PATCH 0/3] Add more winsymlinks values

[Corinna Vinschen]

On Jul 28 20:55, Jon Turney wrote:
> On 22/07/2021 15:21, Corinna Vinschen wrote:
> > On Jul 22 14:53, Jon Turney wrote:
> > > [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

D'oh!

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

Ok, then, by all means, lets' add a few options to the CYGWIN=winsymlinks
setting.  Just s/WSYM_magic/WSYM_sysfile/.

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

Uh, ok.  That's avoidable, though.  The Cygwin code is lacking a check
for SeCreateSymbolicLinkPrivilege being present and enabled in the
current user token.  This could be done once and then stored in a static
var for later consumption.


Corinna