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