ln command behavior has huge difference from Unix systems #5979
Description
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: sha1Windows 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: DisabledOther 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 busyExpected 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