`ln` command behavior has huge difference from Unix systems

[user-name-beta]

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

$ git --version --build-options
git version 2.52.0.windows.1
cpu: x86_64
built from commit: 2912d8e9b8253723974b7baf1c890273b1a1c5bd
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
libcurl: 8.17.0
OpenSSL: OpenSSL 3.5.4 30 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 10

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

$ cmd.exe /c ver
Microsoft Windows [版本 10.0.18363.1556]
(c) 2019 Microsoft Corporation。保留所有权利。

C:\Users\wttg2\workspace\repos\cp>

Options set during installation

C:\Users\wttg2\workspace\repos\cp>type "D:\Program Files (x86)\Git\etc\install-options.txt" 
Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

No response

Terminal/shell

git-bash

Commands that trigger the issue

$ ln -s C:/Windows LINK
ln: failed to create symbolic link 'LINK': Device or resource busy

Expected behaviour

It will create a special file named LINK containing the information to locate "C:\Windows", which is almost like Unix.

Actual behaviour

It tries to copy the whole C:\Windows directory to a new directory named LINK without any explicit information.

Repository

No response

[dscho]

This is a known issue in MSYS2: https://www.msys2.org/docs/symlinks/#known-issues

There is msys2/msys2-runtime#114 to fix this issue by switching the default to create native Windows symbolic links whenever possible, but that would have ramifications on Git's CI test suite because:

1. Support for symbolic links has not yet been upstreamed from Git for Windows to Git.
2. Not even Git for Windows would pass the test suite (I started preparing to fix that, but the part that applies to upstream Git does not yet pass the test suite, and I plan on fixing this in my ample spare time).