`ln`: `Junction` may need to be added to the options of `winsymlinks`

[wszqkzqk]

Now winsymlink has following options to make soft links (ln -s 'file' 'target'):

• winsymlink:lnk: to make windows shortcut files
• winsymlink:native or winsymlink:nativestrict: to make windows symlinks (the same as mklink /d 'target' 'file')
• winsymlink: to copy the file of directory

But it is not possible to make windows junctions (mkdir /j 'target' 'file'), and that's not convenient, because only junctions support to make a symlink in a symlink directory.

So junction may need to be added to the options of winsymlinks

[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.

[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]

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.