Msys2-packages: Coreutils: ln --symbolic creates hard links

[baldrianbandit]

Running mintty with bash within a fresh install of msys2-20150512 and trying to create a symbolic link with
ln -s
results in a hard link. Does anyone else experience this?

[Alexpux]

MSYS2 DO NOT support creating symlinks like Cygwin.
You can only use native Windows symlinks by editing startup *.bat file and uncomment line with MSYS=winsymlinks:nativestrict

[baldrianbandit]

Alright, thanks!

[stahta01]

I had to edit this "msys2_shell.cmd" file with the current MSys release.

Tim S.

[bab9e9]

Wow! I just ran afoul of this crazy "feature". Try
$ ln -s /c /foo
and you are hosed!
Why would ln ever copy files?!! ("I am shocked, shocked!")

Your "solution" to makefiles using "ln -s" to copy it all over drops a big bomb on the unsuspecting user.
It would, in my opinion, be far better to error out of ln -s with a decent explanation of why you "can't do that" in Windows.
Then the makefile can be modified to avoid that feature. Using cp, if that is a viable solution. But leaving such a dangerous, wasteful, unexpected operation in "ls -s" is surely far more trouble.

The MSYS=winsymlinks:nativestrict option is said to require admin privileges, which I don't have on this computer, so that's a non-starter for me.

[bab9e9]

If I use MSYS=winsymlinks:nativestrict then I get the behavior I prefer to "crazy copy".

$ ln /e eHard
ln: /e: hard link not allowed for directory

$ ln -s /e eHard
ln: failed to create symbolic link 'eHard': Operation not permitted

At least this makes sense. Faking a link by a copy just seems wrong.
By the way, info ln says this:
‘-s’
‘--symbolic’
Make symbolic links instead of hard links. This option merely
produces an error message on systems that do not support symbolic
links.

That is not true when you don't have MSYS=winsymlinks:nativestrict.

[ankostis]

There should be another option for those of use who work explictely with MSYS2 executables:

MSYS=winsymlinks:cygwin

And use text-files like CYGWIN does.

[icasimpan]

There's this scripted solution in https://superuser.com/questions/550732/use-mklink-in-msys that you may want to adapt (see JimmyZ comment)

[ankostis]

@icasimpan are you talking to me :-)?

[niklasholm]

I agree with @bab9e9, ln -s should really show a warning instead of silently changing behavior unbeknownst to the user.

[albfan]

I only find this config under ini files. Searching for winsymlinks:nativestrict I found in

/c/msys64$ rg nativestrict
mingw32.ini
1:#MSYS=winsymlinks:nativestrict

mingw64.ini
1:#MSYS=winsymlinks:nativestrict

msys2.ini
1:#MSYS=winsymlinks:nativestrict

msys2_shell.cmd
8:rem set MSYS=winsymlinks:nativestrict

It only works with msys2 as administrator. But how do one make it work in mingw64, and in git-for-windows? and without open as administrator? I think this script must be shipped with coreutils https://superuser.com/a/1244302

[niklasholm]

For anyone interested, I've used this workaround successfully to warn against accidentally copying files. Just put in your .profile.

ln_test_args() {
    for arg in "$@"; do
        case "$arg" in
            --*)
                case "$arg" in
                    --symbolic)
                        return 1
                        ;;
                    --)
                        break;
                        ;;
                esac
                ;;
            -*)
                while read -r -n 1 char; do
                    [ "$char" = s ] && return 1
                done << EOF
$arg
EOF
                ;;
        esac
    done
    return 0
}

ln_wrapper() {
    if ln_test_args "$@"; then
        command ln "$@"
    else
        >&2 echo "WARNING: symbolic links not supported. To override, use \"\\ln $@\""
    fi
}

alias ln='ln_wrapper'

[texasbruce]

If it does not work, it should be turned off and warn the user -s is not supported.

Current behavior does not work and no error is presented, which caused much time was spent on debugging.

Do not see the reason this should be closed.

[abmclin]

Recently installed MSYS2 64-bit 20180531 version on Windows 10 and wish to enable MSYS=winsymlinks:nativestrict but the documented method of uncommenting the relevant line in C:\msys64\mysys2.ini appears to no longer work. That file doesn't seem to be read by msys2 executable, I tested by adding a new variable line but it's not being picked up when I restart msys2.

Editing msys2_shell.cmd doesn't work either.

Please advise on the correct method or if this is a new bug?

[abmclin]

More information, the installation process creates an app shortcut that points to mintty.exe located in C:\msys64\usr\bin which bypasses whatever you put in the .ini configuration file. If you instead create a shortcut to msys2.exe located in C:\msys64 then the configuration file works as expected when you invoke msys2.exe instead.

[texasbruce]

I would recommend you to just use mklink in elevated CMD. I personally very rarely create new symlink so it doesn't bother me as much.

The support for native symlink is terrible in msys2 and I tried to write some JS/Bash/CMD scripts myself to get elevation and create symlinks inside but wasn't much of success.

[abmclin]

Yes, I use mklink to do any symlinking in Windows. I wanted to use MSYS=winsymlinks:nativestrict as a way to disable the default copying behavior of ln -s.

I figured out that to ensure the config file is actually read, have to directly invoke msys2.exe located in the installation directory so use that one and pin it to your taskbar and use it from now one to start msys2.

[RobertHaileySlalomBuild]

Regarding:

[...snip...]
alias ln='ln_wrapper'

I think it would be easier to simply:

alias ln=false

[echuber2]

The alias trick seems to hard to ensure across scripts and stuff. This definitely seems like something that needs to be addressed though.

[niklasholm]

@echuber2 The only way to ensure it across scripts and stuff is to patch the actual binary.