On Jul 21 12:24, Christian Franke wrote: > 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? > > > > 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? > > > > WSL compatible symlinks introduce several issues with non-Cygwin > Copy/Archive/Backup tools (robocopy behaves strange, 7-Zip stores these as > empty files, ...).
Native backup tools are supposed to store unknown reparse points verbatim, If they don't, it's a bug in these tools which not only affects Cygwin, but every unknown reparse point. Corinna
