Windows git does not checkout symlinks, even if SeCreateSymbolicLinkPrivilege is enabled

[gisburn]

Existing issues matching what you're seeing

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

Git for Windows version

$ '/cygdrive/c/Program Files/Git/cmd/git' --version
git version 2.49.1.windows.1

Windows version

Windows 10

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

$ cmd.exe /C 'ver'
Microsoft Windows [Version 10.0.19045.6282]

Options set during installation

-

Other interesting things

No response

Terminal/shell

Commands that trigger the issue

Testcase:
(Note that the testcase is run from Cygwin, but the checkout is done using Windows git. We do that so the symlink is correctly stored in the git repro, and Windows git is only used for clone/checkout to demonstrate the bug.)
---- snip ----
set -o xtrace
set -o errexit

rm -Rf newgitproj newgitproj_cloned

#
# Create via Cygwin git
#
mkdir newgitproj
cd newgitproj
git init --initial-branch='master'
git config --global --add safe.directory "$PWD"
git config --global --add safe.directory "$PWD/.git"
 
printf 'Hello, Git symlink test!\n' >'README.md'
git add 'README.md'
git commit -m 'Add README file'

ln -s 'README.md' 'README_link.md'
git add 'README_link.md'
git commit -m 'Add symlink to README file'
cd ..

#
# clone via Windows git
#
'/cygdrive/c/Program Files/Git/cmd/git' clone newgitproj newgitproj_cloned
cd newgitproj_cloned
if [[ ! -L 'README_link.md' ]] ; then
	printf '## Test failed\n'
	exit 1
fi

printf '## Test OK\n'
exit 0
# EOF.
---- snip ----

Expected behaviour

'/cygdrive/c/Program Files/Git/cmd/git' clone newgitproj newgitproj_cloned should checkout the symlonk correctly, OR bail out with an ERROR if it cannot create a symlink

Actual behaviour

It creates a plain file, which is not a symlink. UNIX (Solaris, Linux) and Cygwin (POSIX layer on top of Win32) do this correctly

Repository

[rimrul]

Options set during installation

Filling that out would have been helpful.

Note that the testcase is run from Cygwin
[…]
ln -s 'README.md' 'README_link.md'

Did that even create a proper native symlink? (does your $CYGWIN contain winsymlinks:nativestrict?) This would have been easier to demo with mklink.

[becm]

@gisburn you can check if your results match the table in #5517.
If so, it's likely caused by an Cygwin update, needing a special environment variable to allow native symlinks.

MSYS=winsymlinks:nativestrict git clone …

or in the native Win32 command interpreter:

set MSYS=winsymlinks:nativestrict
git clone …

[gisburn]

Options set during installation

Filling that out would have been helpful.

Note that the testcase is run from Cygwin
[…]
ln -s 'README.md' 'README_link.md'

Did that even create a proper native symlink? (does your $CYGWIN contain winsymlinks:nativestrict?) This would have been easier to demo with mklink.

Yes, it uses native symlinks. I can even see the (correct) creation with Cygwin git in the kernel debugger, and the reading of the reparse point. Cloning the repro with Solaris, Linux or Cygwin git also correctly creates the symlink.

In the meantime I got deeply into the code and found that this fixes the issue for native Win32 git:
'/cygdrive/c/Program Files/Git/cmd/git' clone -c core.symlinks=true newgitproj newgitproj_cloned

Two questions:

• why is core.symlinks=true not the default for native Win32 git ?
• why is there no ERROR or WARNING if symlinks are replaced by regular files ?

[gisburn]

@gisburn you can check if your results match the table in #5517. If so, it's likely caused by a Cygwin update, needing a special environment variable to allow native symlinks.

MSYS=winsymlinks:nativestrict git clone …

or in the native Win32 command interpreter:

set MSYS=winsymlinks:nativestrict
git clone …

The clone is done by native Win32 git, not Cygwin git. I only used Cygwin git to create the repro...

[gisburn]

BTW: Can we please forget about the involvement of "Cygwin" ? Please just assume that someone somehow created a git repro which stores a symlink, and that NATIVE Win32 git chokes on that unless core.symlinks=true is set.

[gisburn]

BTW: Can we please forget about the involvement of "Cygwin" ? Please just assume that someone somehow created a git repro which stores a symlink, and that NATIVE Win32 git chokes on that unless core.symlinks=true is set.

Chokes on that when trying to clone it...

[rimrul]

why is core.symlinks=true not the default for native Win32 git 

Because SeCreateSymbolicLinkPrivilege still isn't included in default user permissions and we have no way of ensuring all current and future users of a Computer have SeCreateSymbolicLinkPrivilege enabled.

Also there is a page in the installer specifically asking about this.

why is there no ERROR

The same reason Cygwin git doesn't error out on winsymlinks:sys or winsymlinks:lnk. It's working as intended with these settings.

or WARNING if symlinks are replaced by regular files

Should probably be advice, not a warning. But no one has cared about it enough in the time since ~2008 to add such advice.