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.
