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
