Well, Cygwin had something like support for symbolic links, using .lnk files for the emulation.

Cygwin not onlyhad, it still has symlinks like that - except the docs suggest that the*.lnk are not the default. The cygwin docs say this about their default symlinkshttps://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks

special reparse points shared with WSL (on NTFS on Windows 10 1607 or later)
plain files with the system attribute, containing a magic cookie followed by the path to which the link points.

The "shortcut" style links are something different.

The new Developer Mode feature is OK, but it's got a big warning on it when you enable it and enterprises therefore don't want to enable it:

Turning on developer mode, including installing and running apps from outside the Microsoft Store, could expose your device and personal data to security risks or harm your device.

https://stackoverflow.com/questions/74613686/what-does-the-warning-in-developer-mode-mean

I setexport MSYS=winsymlinks:sys as I believe this restores the cygwin default special reparse point symlinks, which is fine by me. I also foundhttps://carltonf.github.io/post/symbolic-links-on-windows sort of helpful in dumbing it down

MSYS=winsymlinks:sys

This mode is incompatible with regular Win32 programs; They won't understand those symlinks and misinterpret them all the time. That is an okay stance to take for Cygwin, which wants you to stay within its ecosystem. It is not an okay stance for MSYS2 which wants to integrate with native Win32 programs as much as possible.

The new Developer Mode feature is OK, but it's got a big warning on it when you enable it and enterprises therefore don't want to enable it:

Turning on developer mode, including installing and running apps from outside the Microsoft Store, could expose your device and personal data to security risks or harm your device.

Yes, developer mode comes with a lot of liberties that developing code requires. Nevertheless, it isthe mode in which Windows users can create symbolic links in modern Windows without requiring an elevated process (which would increase the security risk a lot more than Developer Mode).

In any case, the mode I introduce here, and which I propose to promote to eventually be the default, retains backwards-compatibility in a fashion, by falling back to MSYS2's current behavior if symbolic links cannot be created.

I am thinking, would it make sense to try to generalize this? maybe something likewinsymlinks:native:deepcopy or something? There's a sort of ambivalence in me: I don't want to just add another symlink type, but I also don't want to increase the combinatorial complexity of symlinks.

I am thinking, would it make sense to try to generalize this?

Can you think of any use case where a different config/order would be preferred by users?

Not necessarily, it's just now we have a lot of seemingly-poorly-defined fallback cases:

• native (or nativestrict if target isspecial) falls back todefault
• default is actually wsl with a fallback to sysfile
• deepcopy falls back to sysfile if target isspecial

I guess now that I write it out, that's not too bad, everything that falls back eventually falls back to sysfile. Perhaps deepcopy should fall back todefault also now for consistency (the wsl stuff obviously didn't exist when deepcopy was written). Moving deepcopy up into the block where native/strict happens would make it more obvious that it's a fallback case too.

Perhaps deepcopy should fall back todefault also now for consistency (the wsl stuff obviously didn't exist when deepcopy was written).

My rationale was: deepcopy exists only as a Win32-compatible fall-back if symlink support does not exist, and symlink support predates WSL (and both require Developer Mode to be enabled IIRC).

But then, this entire PR is about movingoff of deepcopy in the first place, preparing for a time when MSYS2 drops support for Windows versions where symlinks can only be created when running elevated.

FWIW@jeremyd2019 I really like the refactoring you did, moving the deepcopy code into its own function, I'd just suggest to do it as a preparatory, separate commit instead of squashing it in.

symlink support predates WSL (and both require Developer Mode to be enabled IIRC)

Not to derail into something off-topic - not sure if you're saying WSL2 requires Developer Mode - it doesn't. Probably easier to get WSL2 to a level that meets enterprise security than Developer Mode, altho that's no simple thing either.

There's been a trend for tools to just use junctions instead since they don't require admin privileges - you can see a bit of context atkubernetes-sigs/krew#843 - obv junctions just link a folder, but in many cases that can suffice

There's been a trend for tools to just use junctions instead since they don't require admin privileges

@jcrben It had been a trend, but thankfully it's no longer all that common. See e.g.this insightful comment for an explanation. Here's an excerpt:

Feature	Unix	Windows symlink	Windows junction
Target is relative to source directory	yes	yes	no
Target is relative to current computer	yes [1]	yes	no
Target is absolute	no	yes [2]	yes [3]
Link is resolved by	client	client	server

[1] Symlinks to absolute paths are resolved by the client and thus relative to the client computer. E.g. if/usr is mounted to some central network drive, the symlink/usr/local/etc -> /etc/local refers to/etc/local on the client.
[2] Via UNC path, e.g.\\server\share\path.
[3] Via local path, e.g.C:\path or\\?\Volume{...}\path.

tl;dr Windows junctions are nowhere close to being a valid symlink replacement.

@dscho well, in some ways using junctions is becoming more common - fnm switched to junctions in 2021, volta just did in 2024, jbangdev did it in 2024 at my urging, kubectl plugin manager krew may also do it. avoiding a complex and scary step of enabling Developer Mode is pretty nice. wish we could get symlinks on Windows without enabling Developer Mode. See also:Why do you have to be an admin to create a symlink in Windows?

@jcrben writes:

wish we could get symlinks on Windows without enabling Developer Mode. See also:Why do you have to be an admin to create a symlink in Windows?

Exactly that. You don't need the Developer Mode or become elevated every time you create a symlink. AssigningSeCreateSymbolicLinkPrivilege to your user once is enough. That's what I did in the past on my w10, and I am running fine since.

in some ways using junctions is becoming more common

@jcrben Yes, and that's true even when mentioning better-known projects (I never heard about your examples, but IIRCpnpm is an example where junctions are used).

The important thing to keep in mind? The usage resembles Unix mount points, much more than symbolic links. I do encourage you to studythe insightful comment about this that I linked earlier.

AssigningSeCreateSymbolicLinkPrivilege to your user once is enough. That's what I did in the past on my w10, and I am running fine since.

@sskras That's enticing, but leaves the reader hanging for a clear description how to do that. In other words, your comment is too terse, saves too much on time at the cost of being less helpful than it could be. Please do fill in the blanks.

https://packages.msys2.org/packages/mingw-w64-x86_64-editrights
https://cygwin.com/cgit/cygwin-apps/editrights/tree/editrights.README

editrights -u YourUser -a SeCreateSymbolicLinkPrivilege

? (untested)

@dscho commented3 days ago

AssigningSeCreateSymbolicLinkPrivilege to your user once is enough. That's what I did in the past on my w10, and I am running fine since.

@sskras That's enticing, but leaves the reader hanging for a clear description how to do that. [...] Please do fill in the blanks.

OK. There are different ways/tools to configure this:

1, usingsecpol.msc GUI.
2, usingsecedit.exe CLI.
3, usingntrights.exe old CLI (it was present on the old Windows Server Resource Kit only, and it harder to find).
4, using 3rd party tools, eg:

• https://github.com/pandell/NTRightsNet (C#)
• https://github.com/jcasale/UserRights (C#)
• https://github.com/petemoore/ntr (Golang)
• https://github.com/zippy1981/ntrights (C++ PoC, requires hardcoding)

I didn't think earlier a Windows developer would need guidance on that, but now visualized usage of the 1st tool:

0. Open "Run" dialog, typesecpol.msc.
1. Press OK ("Local Security Policy" opens).
2. Navigate to "Local Policies", expand it.
3. Navigate to "User Rights Assignment".
4. Double-click "Create symbolic links" ("Create symbolic links Properties" dialog opens).
5. Click "Add User or Group..." ("Select Users or Groups" dialog opens).
6. Type in the needed username.
7. Press OK twice.
8. Check if the username already occurs on the line from step 4.
9. Maybe rungpupdate after that (I already forgot / didn't test that).

@jeremyd2019 commented3 days ago

https://packages.msys2.org/packages/mingw-w64-x86_64-editrightshttps://cygwin.com/cgit/cygwin-apps/editrights/tree/editrights.README

editrights -u YourUser -a SeCreateSymbolicLinkPrivilege

? (untested)

Thanks, I didn't know about this tool! Might be a nice addition to the list above.

Honestly, I was thinking more about an automatable solution that requires nothing but PowerShell, something like:

# Export the current security settings to a file$SecEditExportFile="$env:TEMP\secedit.inf"secedit/export/cfg$SecEditExportFile/areas USER_RIGHTS# Modify the security settings file to include the privilege for the user$User="DOMAIN\User"$Privilege="SeCreateSymbolicLinkPrivilege"# Read the exported settings file$lines=Get-Content$SecEditExportFile# Add the privilege for the user$index=$lines.IndexOf("[Privilege Rights]")$privilegeLine=$lines[$index..($lines.Length-1)]|Where-Object {$_-match"^$Privilege" }if ($privilegeLine) {$existingValues=$privilegeLine-replace"$Privilege =",""$newValues="$existingValues,$User"$lines[$lines.IndexOf($privilegeLine)]="$Privilege =$newValues"}else {$lines+="$Privilege =$User"}# Write the modified settings back to the file$lines|Set-Content$SecEditExportFile# Import the modified security settings:secedit/configure/db secedit.sdb/cfg$SecEditExportFile/areas USER_RIGHTS# Refresh the policy:gpupdate/force

Since this here is a public bug tracker, one must assume that people might find this and would be delighted by guidance how to achieve the goal they set out to accomplish when trying to find more information.

I didn't think earlier a Windows developer would need guidance on that, but now visualized usage of the 1st tool:

Stating that you didn't think earlier a Windows developer would need guidance on that may very well come over as pretty smug and arrogant, and is therefore potentially something you'd like to avoid.

@jeremyd2019,editrights that you found seems to work just fine:

Thank you.

@dscho wrote:

Honestly, I was thinking more about an automatable solution that requires nothing but PowerShell, something like:

  ...secedit/export/cfg$SecEditExportFile/areas USER_RIGHTS  ...secedit/configure/db secedit.sdb/cfg$SecEditExportFile/areas USER_RIGHTS  ...

It still relies on runningsecedit a couple of times internally. Could be done quickly using sh + AWK too, eg:

Easily extendable to add the newSeCreateSymbolicLinkPrivilege = ... line in case it was missing, but unsure if that's needed.

IIUC this would mean that the current install of the supported Windows versions (w10, w11) is misconfigured or pretty broken, eg. having corrupt Security Database. But I am not against that.

And... how is it better than usingeditrights ?

Since this here is a public bug tracker, one must assume that people might find this and would be delighted by guidance how to achieve the goal they set out to accomplish when trying to find more information.

I see your point. For starters, as an ordinary user of MSYS2 I hope to find such info on the installation page, eg:https://www.msys2.org/#installation

Crossing fingers so the ways get discussed properly and then get better publicity. Cheers :)

I didn't think earlier a Windows developer would need guidance on that, but now visualized usage of the 1st tool:

Stating that you didn't think earlier a Windows developer would need guidance on that may very well come over as pretty smug and arrogant, and is therefore potentially something you'd like to avoid.

That's sad. What drove me is not the pride, but the ambiguity of the ways to solve this + my aim at keeping the Signal-to-Noise ratio high. I hope I proved that by illustrating two of these ways.

Came here looking for answers, read the thread, got good info.

The conversation is fine.
Not smug, just direct.

Probably the main concern is making this work out of the box in the corporate environment.
Coorporate IT tends to be very defensive about exceptions that bubble up in GUI settings like "Developer Mode".

Automatically enabling NTFS symlinks with an opt-out (like Git-Bash) should be the chief goal here.
This is merely codifying the principles of no harm and implicit permission granted through SeCreateSymbolicLinkPrivilege.