git bash should error on 'ln -s' if it is not enabled

[ernstklrb]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? 2.28.0
• Is it 32-bit or 64-bit? 64

$ git --version --build-options
git version 2.28.0.windows.1
cpu: x86_64
built from commit: 77982caf269b7ee713a76da2bcf260c34d3bf7a7
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 10 64bit

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18363.1379]

• What options did you set as part of the installation? Or did you choose the
  defaults? I do not know - it is installed by Admin.

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

** insert your machine's response here **

• Any other interesting things about your environment that might be related
  to the issue you're seeing?
  none

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

This report is about 'git bash' itself, not about git.

• What I see

Apparently, when creating symlinks is not enabled at install time, git bash will resort to copying the source to the target instead., if a ln -s source target command is issued. This is what I see from issuing stat on the source and the result.

• What I would like to see

In case symlinking has not been enabled, ln -s should stop with an error (instead of resorting to a semantically incompatible alternative behavior).

[dscho]

@ernstklrb you have a good point. MSYS2's Bash (which we use in Git for Windows) does not create symlinks by default.

However, there is a "knob" you can turn: setting the environment variable MSYS=winsymlinks:nativestrict (see Cygwin's documentation, MSYS is the MSYS2 equivalent of CYGWIN).

Now, we already have prior art for modifying the MSYS variable when launching Git Bash: git-for-windows/build-extra@b73b4e3

Essentially, you can add the line MSYS=winsymlinks:nativestrict to /etc/git-bash.config (or modify an existing line setting MSYS, multiple options can be specified, separated by blanks).

Could you try that (as administrator, because /etc/git-bash.config is actually C:\Program Files\Git\etc\git-bash.config) and see whether that works as intended?

If so, we can add that setting automatically when support for symbolic links is enabled in Git for Windows' installer.

[ernstklrb]

I have tested with a fresh installation of git for windows, with "symbolic links" enabled in the installer.
I get the following behavior:

• before adding the MSYS=... line:
  'ln -s' silently creates a copy instead
• after the line added (actually, the file git-bash.config had to be freshly created)
  ln: failed to create symbolic link 'c.txt': Operation not permitted

Maybe a better message would have been "Operation not possible", but I guess that is outside of your scope

[ernstklrb]

Now I did a second test, again with a fresh installation (after uninstallation and completely removing c:\Program Files\Git).

This time without enabling symbolic links.

I get the same behavior as in the "with symlinks" case.

So I think you either need to add the MSYS-line in both cases (with and without symlinks enabled), or maybe just in this second case without symlinks enabled.

But it is not sufficient to do it just in the "enabled" case you referred to in your post.

[dscho]

ln: failed to create symbolic link 'c.txt': Operation not permitted

Can you verify that mklink can create symlinks in your setup (this should be the case if you enabled Developer Mode)?

[dscho]

I get the same behavior as in the "with symlinks" case.

Wait, I am confused. What was the "with symlinks" case? Or better: what was the behavior?

So I think you either need to add the MSYS-line in both cases (with and without symlinks enabled), or maybe just in this second case without symlinks enabled.

I think you're right on that. Unless we can guarantee that git-bash.config is removed (and potentially recreated) when reinstalling.

But that's not what I am trying to work out right now. I am trying to work out how to get Git Bash to expose the ln -s behavior that you want.

[rimrul]

Wait, I am confused. What was the "with symlinks" case?

If I undertand it correctly they're just saying ln -s behaves the same, wether you enable symlinks in the installer or not, it only depends on the MSYS environment variable.

[dscho]

Wait, I am confused. What was the "with symlinks" case?

If I undertand it correctly they're just saying ln -s behaves the same, wether you enable symlinks in the installer or not, it only depends on the MSYS environment variable.

Yes, that would make sense because Bash does not care about Git's config, nor does the MSYS2 runtime.

[ernstklrb]

ln: failed to create symbolic link 'c.txt': Operation not permitted

Can you verify that mklink can create symlinks in your setup (this should be the case if you enabled Developer Mode)?

So when I tried "MSYS=winsymlinks:nativestrict" first, I did not have permissions for doing mklink. This resulted in 'ln -s' erroring out, like I would expect.

Now, with permissions for mklink enabled as per your wiki entry, the behavior has changed: 'ln -s' in git bash will create a symlink.

[dscho]

Now, with permissions for mklink enabled as per your wiki entry, the behavior has changed: 'ln -s' in git bash will create a symlink.

Ouch. We should have edited https://github.com/git-for-windows/git/wiki/Symbolic-Links#allowing-non-administrators-to-create-symbolic-links a long time ago, I think, to prominently encourage Developer Mode, and only as a fall-back to do the permission dance. Unfortunately, I lack the time to edit this page...

[ernstklrb]

Improving the documentation reg. symbolic links might be good.
Regardless, I think it is worth improving the default behavior in the non-developer-mode case to not silently copy instead of symlinking. Because

• this is about the initial behavior of git bash after installation without any "tweaking"
• in a corporate environment, e.g., it might be difficult to get mklink permissions enabled

[dscho]

Improving the documentation reg. symbolic links might be good.

Would you be so kind?

[dscho]

I think it is worth improving the default behavior in the non-developer-mode case to not silently copy instead of symlinking.

That's a decision for the MSYS2 project, though...

[ernstklrb]

I think it is worth improving the default behavior in the non-developer-mode case to not silently copy instead of symlinking.

That's a decision for the MSYS2 project, though...

For git-bash, I guess, the git-for-windows project can decide how to handle the symlink issue.

I suggest you add MSYS=winsymlinks:nativestrict to /etc/git-bash.config on installation. (At least when /etc/git-bash.config does not yet exist.) Rather provoke a clear error message and avoid bad surprises later with "symlinks" that happen to be copies.