`ln`: `Junction` may need to be added to the options of `winsymlinks` about msys2-runtime

[dscho]

Directory junctions are not really an equivalent of Unix' symbolic links, but more like Unix' mount points. See e.g. this excellent argument (the entire thread is worth reading).

For example, you cannot create a junction for a file. Plus, junctions are resolved in the filesystem layer, unlike symbolic links.

[jeremyd2019]

In my experience, upstream is very reluctant to add new options, for the understandable reason that they increase the number of code paths that need testing, and may harbor issues that only occur when some obscure option or combination of options are set.

This fork has been known to add options that upstream will not (such as the 'winsymlink:deepcopy' option) but I think you'd still have a pretty high bar to meet to justify yet another symlink option.

[jeremyd2019]

Thanks for the link, that led me to the response when something like this was proposed upstream in 2015:
https://cygwin.com/pipermail/cygwin-patches/2015q4/008240.html

I can't seem to find any followup beyond this.

[dscho]

Right, so the lead Cygwin developer was less than enthusiastic about this. In the meantime, Windows 10 allows non-admin users to create regular NTFS symlinks when running in Developer mode, therefore I think winsymlinks is pretty good as-is and does not need to pretend that mount points are idempotent to symlinks.

Read: I am in favor of closing this ticket.