[PATCH 0/3] Add more winsymlinks values
Corinna Vinschen
corinna-cygwin@cygwin.com
Thu Jul 29 10:23:21 GMT 2021
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
More information about the Cygwin-patches
mailing list