Closed
Description
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.20.1.windows.1
cpu: x86_64
built from commit: 7c9fbc07db0e2939b36095df45864b8cda19b64f sizeof-long: 4
sizeof-size_t: 8
- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Windows 10 Pro 64-bit
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.17134.472]
- What options did you set as part of the installation? Or did you choose the
defaults?
Using defaults.
- Any other interesting things about your environment that might be related
to the issue you're seeing?
No.
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Bash
- What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.
ln -s target-file link-name
or
ln -s target-dir link-name
- What did you expect to occur after running these commands?
A Windows symbolic link from target file (or target directory) to the link-name specified.
- What actually happened instead?
A copy of the target was done to the link-name.
Possible solution:
Suggest at least including winln.exe
in Git Bash for Windows (this package is available in msys and can be installed using pacman -Su winln
when using Git for Windows SDK. The winln
command checks that user has SeCreateSymbolicLinkPrivilege
to create symbolic link.
FYI: winln
currently does not check if Developer Mode is enabled and will abort creating symlink even though user can create symlinks when this is enabled.
See irakhlin/winln#1