msys2 / msys2-runtime Goto Github PK

The issue:

1. Open cmd.exe.
2. Run C:\msys64\usr\bin\ssh.exe -v somehost.
3. While in the interactive session run some long-running process e.g. top.
4. Press Ctrl+C to interrupt the long-running process inside the interactive session.

Observe: The whole interactive ssh session is terminated with the following debug output:

debug1: channel 0: free: client-session, nchannels 1
Killed by signal 2.

At the same time if you run another MSYS2 package e.g. vim instead of ssh, Ctrl+C works correctly so I'm not sure does it relate to MSYS2 runtime or just OpenSSH package.

In the current active branch this is da43030

I noticed it got dropped upstream now because it's a <win7 thing, so we can drop it too on the next rebase: https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=047eaf9a6b36881a15e43cbea333725b8e59a3b4;hp=b095628ecff1831b250f34d3b6b5787b3f247d63

Hello there,

The following issue is related to the msys2 runtime. I think it's relevant to link it directly here.

git for windows / github issue 3281

Is there a way to make msys2 behave properly with unicode in the windows terminal ?

https://github.com/cygwin/cygwin/releases/tag/cygwin-3.4.3

In winsup/cygwin/fhandler_console.cc there is the following code:

             while (n < total_read)
                {
                  DWORD len;
                  WriteConsoleInputW (p->input_handle, input_rec + n,
                                      min (total_read - n, inrec_size1), &len);
                  n += len;
                }

I was working on a remote login program, and it turns out that if you create a pseudo console in a higher integrity process than the process using the console, WriteConsoleInput will not work (See https://learn.microsoft.com/en-us/answers/questions/1040676/createpseudoconsole-with-reduced-integrity-level.html for details on that)

If WriteConsoleInputW() fails the above code will go into an infinite loop.

I was able to fix my program with great pain and suffering, but things like the above should be written to avoid possible infinite loops. The lack of error checking in general doesn't seem good to me.

Describe the issue

We have an application in golang that implements a test that works well in non-Windows Server installations.

Recently, we configured GitHub Actions for our application, and the only available Windows versions are Windows Server 2016 and Windows Server 2019. We are currently using the Windows Server 2019 version.

The test in mention started failing. Basically, it tries to access an inaccessible folder without any permissions. A chmod representation of this permission could be 0000. We found that a folder and its content can be accessed through the msys2 terminal even with that permission.

I don't know if this is a known issue or the right behavior in msys2. It's my understanding that Windows Server versions might manage ACL permissions quite differently from non-Windows Server versions. I've looked in the issues list and didn't find anything that could help me get this working.

If this is an unknown bug in msys2, it means that an attacker can use it to access system folders even when it's not supposed to happen.

Steps to Reproduce the Problem

1. Creates a directory in the Temp location.
2. Removes all permissions and inheritance from the Security tab inside folder's Properties.
3. The folder should be inaccessible and it content can't be read.
4. Open the msys2 terminal.
5. Access that folder through the terminal, for example with ls -la /c/Users/%USERNAME%/AppData/Local/Temp/%FOLDER%
6. All the content of the directory is listed and can be accessed.

Additional Context:

• Windows Server 2016 Datacenter version 64bit
• Windows Server 2019 Datacenter version 64bit

I want to create two directories, "foo" and "foo.lnk".

The following command sequence works fine:

alb@bla MINGW64 /d/TEMP
$ mkdir foo

alb@bla MINGW64 /d/TEMP
$ mkdir foo.lnk

alb@bla MINGW64 /d/TEMP
$ ls
foo/  foo.lnk/

But if the directory ending with ".lnk" is created first, we run into an error:

alb@bla MINGW64 /d/TEMP
$ mkdir foo.lnk

alb@bla MINGW64 /d/TEMP
$ mkdir foo
mkdir: cannot create directory ‘foo’: File exists

Presumably, foo.lnk is handled as link (or shortcut) due to the .lnk suffix.

Windows shortcuts (.lnk files) are always files, and directories ending with .lnk are just directories.
Msys2 should not handle such directories as links.

While the above example is a constructed one, here's the issue which I stumbled upon: It's not possible to clone the following git repository with msys2 git:

alb@bla MSYS /d/TEMP
$ git clone --depth 1 git://code.qt.io/qt/qtbase.git
...output omitted, but this will fail. See the next command why that is.

alb@bla MSYS /d/TEMP/qtbase
$ git reset --hard
fatal: cannot create directory at 'tests/auto/corelib/io/qdir/testdir/dir.lnk/subdir': File exists

Git failed to create a certain directory. Because the directory tests/auto/corelib/io/qdir/testdir/dir.lnk/subdir.lnk is also part of the repo and was created before.

Side note: Interestingly, git from https://gitforwindows.org/ can clone this repo just fine, though it's also msys2-based.

This is not a critical issue, but some annoying thing that hits people using shared libraries. If some dependency of those libraries is missing, the runtime reports a misleading error showing the name of the first library. The error is misleading because that named library might exist, indeed, while it's a third level dependency the one actually missing.

This was discussed in msys2/setup-msys2#126.

I think the code responsible is here:

msys2-runtime/winsup/cygwin/pinfo.cc

Line 115 in 0eee28b

pinfo::status_exit (DWORD x)

In particular find_first_notloaded_dll() seems to not give good results in many cases..

As said, this is not critical; but just something to be aware of.

Description

cygpath roundtrip produces double slash

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

Microsoft Windows [Version 10.0.19045.2130]

Expected behavior

/

Actual behavior

//

Repro steps

$ cygpath -u `cygpath -m /`
//

Are you willing to submit a PR?

No response

Tried compiling and running tarsnap under the MSYS environment of msys2 and ran into an issue where it tries to save data as a symlink, by making a symlink that points to the value of the data (not an actual file). This works in cygwin and Linux glibc, but not with the msys2-runtime.

Minimal reproduce:

#include <stdio.h>
#include <unistd.h>

int main(int argc, char ** argv) {
	int ret = symlink("non_existent_destination", "source");
	return ret;
}

expected return code is 0, actual is -1

Where I can find documentation/tutorial/instruction for building msys2-runtime. I want to try write some code, compile it and use dll that I will get in msys2 that installed on my computer.

Thanks.

Please let us know when can we have an ARM64 version for Windows on ARM OS. We can help you test We have Windows on Rasberry Pi setup. Please pursue it we at Windows on Rasberry Pi community will be glad to extend support in testing your drivers and tools for ARM64.

My vscode use msys2 as integrated terminal using the following cmdline:

cmd C:\\tools\\msys64\\msys2_shell.cmd -defterm -mingw64 -no-start -use-full-path -here

The PATH seems correct in the integrated terminal:

$ echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mnt/c/Windows/system32:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/ProgramData/chocolatey/lib/gsudo/bin:/mnt/c/Program Files (x86)/GNU/GnuPG/pub:/mnt/c/Program Files/OpenJDK/openjdk-8u282-b08-jre/bin:/mnt/c/Program Files/CMake/bin:/mnt/c/Program Files/nodejs:/mnt/c/tools/msys64/mingw64/bin:/mnt/c/tools/msys64/usr/bin

Then, in this VScode terminal, I call another vscode in a diferent folder:

cmd code another-folder

The new terminal, inside this new vscode instance have prblems in the $PATH:

$ echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:C:\Windows\system32;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\chocolatey\bin;C:\Program Files\Microsoft VS Code\bin;C:\ProgramData\chocolatey\lib\gsudo\bin;

I have this code:

#include <iostream>
#include <windows.h>

int main()
{
    // Ansi output test
    std::cout << "\033[32mgreen\033[0m" << std::endl;
    // Get the current console mode
    DWORD mode = 0;
    if (GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode) == 0)
        std::cout << "failed" << std::endl;

    std::cout << "Mode : " << mode << std::endl;

    // Enable vt100
    SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode | ENABLE_VIRTUAL_TERMINAL_PROCESSING);

    // Ansi output test
    std::cout << "\033[32mgreen\033[0m" << std::endl;
    // Get the current console mode
    mode = 0;
    if (GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode) == 0)
        std::cout << "failed" << std::endl;

    std::cout << "Mode : " << mode << std::endl;

    return 0;
}

When I compile it with the msvc and invoke it from the Windows Terminal then it returns 7.
When I compile it with the ucrt64 g++/clang++ and invoke it from the wterminal then it returns 3.

Here are defines for the return value:

#define ENABLE_PROCESSED_OUTPUT             0x0001
#define ENABLE_WRAP_AT_EOL_OUTPUT           0x0002
#define ENABLE_VIRTUAL_TERMINAL_PROCESSING  0x0004

Problem is that the vt100 support (ENABLE_VIRTUAL_TERMINAL_PROCESSING flag) is disabled when compiled with the ucrt64 g++/clang++ although the terminal obviously supports vt100 processing.

The question is does MSYS2 have any effect on this? Or does MSYS2 modify these flags or it is completely on the winapi, why it is disabled by default on msys2 and enabled on msvc.

I use pacman -Syu to update gcc and g++ yesterday:

(Rev4, Built by MSYS2 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But when I run cpp code below

#include <iostream>
#include <vector>

int main() {
    std::cout << "=====" << std::endl;
    std::vector<float> a(10);  // add vector
    return 0;
}

the program will not output ===== in the stdout console.

Can someone tell me please, in which cases const char* convert(char *dst, size_t dstlen, const char *src) function from file /winsup/cygwin/msys2_path_conv.cc get called?

Thanks.

I was wondering if we should have a new winsymlinks mode which tries to use native symlinks and falls back to deepcopy if that fails. This way we can tell users to enable developer mode to get proper symlinks.

(disclaimer, I have symlinks disabled here to dogfood the defaults, so I haven't used the native stuff really)

edit:

• as pointed out in chat, we should make sure pacman packages don't end up with symlinks still, or figure out how to move symlinks last in the tarball to make the deepcopy fallback work
• what happens with symlinks once dev mode is disabled again?
• what happens on win8.1?

Windows is perfectly okay with environment variables of the form "MESON_SUBDIR=", at least I can set such a variable in e.g. a python script and communicate it to another process. Although cmd.exe's set IIUC will delete it? But msys2 is not a cmd.exe emulator...

However, trying to run this fails:

"env" "MY_ENV=1" "MESON_SOURCE_ROOT=D:\a\meson\meson\test cases\common\51 run target" \
    "MESON_BUILD_ROOT=D:\a\meson\meson\tmp59june4u" "MESON_SUBDIR=" \
    "MESONINTROSPECT=D:\a\_temp\msys64\mingw32\bin\python3.exe D:\a\meson\meson\meson.py introspect" \
    "D:\a\_temp\msys64\mingw32\bin\python3.exe" "D:/a/meson/meson/test cases/common/51 run target/check-env.py" \
    "../test cases/common/51 run target" "." "../test cases/common/51 run target/"

Traceback (most recent call last):
  File "D:\a\meson\meson\test cases\common\51 run target\check-env.py", line 8, in <module>
    assert 'MESON_SUBDIR' in os.environ
AssertionError

This was brought up e.g. in msys2/MINGW-packages#1599 in the past.

...

It seems very wrong for the msys2 runtime to do this. If I run python3.exe basically-env.py "MESON_SUBDIR=" <script> it works flawlessly, but if I run env.exe "MESON_SUBDIR=" <script> it refuses to work because it's trying to emulate cmd.exe instead of Unix?

Unfortunately, Meson needs this functionality, because "the concept of being empty" is crucial information that needs to be passed from one process to another. I would like to pass this information via the most efficient program for setting such information, but it looks like I might need to restrict that to "real unixes".

Thoughts? Is it possible this restriction can be lifted?

There has been a regression in msys2-runtime when it comes to invoking cmd.exe

Here is the old expected behaviour with msys2-runtime-3.3.5-3 or earlier:

pete@good_msys MINGW32 ~
$ uname -a
MINGW32_NT-10.0-22621 good_msys 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys

pete@good_msys MINGW32 ~
$ cmd.exe /c 'echo BLAH'
BLAH

And this is what happens when upgrading to msys2-runtime-3.3.6-1 or later:

pete@bad_msys MINGW32 ~
$ uname -a
MINGW32_NT-10.0-22621 bad_msys 3.3.6-341.x86_64 2022-09-20 22:07 UTC x86_64 Msys

pete@bad_msys MINGW32 ~
$ cmd.exe /c 'echo BLAH'
bash: /c/Windows/System32/cmd.exe: Bad address

This issue has been confirmed by other people (on the Discord channel) and whereas, for the simple example above, one workaround has been found, which consists of doubling the '/' (cmd.exe //c 'echo BLAH'), such a workaround does not appear to be effective with more complex command invocations, such as one I am using in a bash script where signtool.exe must be invoked in order to digitally sing a PowerShell script. In this case, when using //, the Bad address error becomes '\"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64\signtool\"' is not recognized as an internal or external command, operable program or batch file.

I am therefore opening this issue to ask the msys2-runtime developers to investigate the changes that occurred between 3.3.5-3 and 3.3.6-1, in order to fix this regression, so that invoking a complex command such as cmd.exe /c '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64\signtool" sign /v /sha1 3dbc3a2a0e9ce8803b422cfdbc60acd33164965d /fd SHA256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td SHA256 Fido.ps1' from bash will work as it did before.

I was build dll with --enable_debugging in configure and -DDEBUGGING=1 in make but still hasn`t get debug output.
Please tell me that I should do to see debug_printf output

Thanks.

Hello!

I hope I am in the right place for my question!

As mentioned in issue #58 after I installed Git for Windows v2.36.0 (with msys v3.34) it seems that git bash can't access network drives.
The following problems occurs when I start a git bash.

First the console displays:
: /v//.bash_profile: Too many levels of symbolic links

Furthermore it seems, that msys2 can't load my window settings (v:\.minttyrc) just like my bash_history.
When I try:
cd $HOME it quits with:
bash: cd: /v/: Too many levels of symbolic links

Result of uname -a: MINGW64_NT-10.0-19044 TESTPC 3.3.4-341.x86_64

Only after I have set the environment variable MSYS to nonativeinnerlinks the bash "seems to behave like before".
I saw the merged Pull Request #73 and thought that this misbehavior had been fixed.

Now I would like to know if the environment setting is nevertheless to be set?

The problem I'm having is building and linking against a library that I'm doing unit test on. This previously worked in msys2 for many years (though a previous release broke it in the same way and was subsequently fixed). The problem I'm observing is that some standard lib functions are not linking correctly into my application if used in the library under test. However, if the unit tests use that same function then it links correctly. The failure is repeatable on multiple computer.

The following tools are used:

1. Windows 10+
2. Msys2 - Installer build date - Feb 10, 2022
3. Gcc v11.2.0
4. binutils v2.37
5. Cmake v3.22.1
6. Cmocka v1.1.5
7. lcov v1.13 (not used due to crash but would run and generate coverage report)

I've attached a simple project to illustrate the issue. The interesting thing is that the linking fails when the strncpy() call is in the library being unit tested. However, if we add a call to strncpy() to the unit test then the linker finds it in the library and correctly links the test.

The code under tests is located in the source files of relevance are:
./msys2_gcc_v11_bug.c //Source below:

void msys2_gcc_v11_string_linker_bug(char * folderPath, size_t folderPathLen, const char  * fname)
{
        folderPath[folderPathLen] = '/';
        strncpy(&folderPath[folderPathLen + 1], fname, strlen(fname));
}

./unit_test/test-msys2_gcc_v11_bug.c // Test function - note #if 0 which allows the linking to operate correct if enabled

static void msys2_gcc_v11_bug_test(void ** state)
{
        #define TEST_BASE_PATH_STR "LOGS/Example"
        const char * test_basePathStr = TEST_BASE_PATH_STR;

        /* Allocate a buffer big enough to contain the path plus the largest file name. */
        char nodePathStr[64];
        strcpy(nodePathStr, TEST_BASE_PATH_STR);

        /* Enable a use of strncpy() in the test and the function is correctly link
         * to the application. Leave this disabled and the application segfaults
         * when the call to strncpy in the msys_gcc_v11_bug.c code is made. */
        #if 0

        char temp[64];
        strncpy(temp, "FORCED string", 64);
        printf(temp);
        #endif

        const size_t nodePathStrLen = strlen(nodePathStr);
        msys2_gcc_v11_string_linker_bug(nodePathStr, nodePathStrLen, "test_file");


        #undef TEST_BASE_PATH_STR

}

msys2_gcc_v11_bug.zip

So far I have traced the symbols using objdump at each stage of the compilation and noted that the symbols present and weak after the initial compile of the library under test. I've also recompiled and reinstalled CMake using the msys2 gcc v11 tool chain to see if that made any difference and it did not.

Using an up-to-date Msys2 install I see that /usr/lib/libc.a, /usr/lib/libm.a, /usr/lib/libdl.a, and potentially others use the incorrect name of the msys DLL:

dlltool -I /usr/lib/libc.a
msys_2_0.dll

There is no DLL of that name. The correct name is likely msys-2.0.dll. /usr/lib/libg.a gets this right even though it is a part of the same package: msys2-runtime-devel. Also of note is that these are import libraries using the suffix .a, while most other packages use .dll.a. Not sure if that's an issue though.

I ran into this issue because of msys2/MSYS2-packages#2357. ctypes.util.find_library('dl') returns msys_2_0.dll which will not load in ctypes.CDLL().

While NTFS supports hardlinks, exFAT does not. This prevents some packages to be installed in an msys2 installation that is on an exFAT-formatted drive.

Instead of having all those packages created without hardlinks, or expect some "dereferencing" feature to get implemented in libarchive, I wonder if it's possible / a good idea to have a wrapper for link() that allows users to choose whether to do deep copy for link() like we do for symlink().

Hi, I wonder which license the runtime msys-2.0.dll is distributed with.
I think the upstream cygwin has changed to LGPL since 2016, and from winsup/CYGWIN_LICENSE, it seems that the runtime should be LGPL. However both GPL and LGPL texts are in the project root, and I'm not sure if msys-2.0.dll contains code other than winsup.
Thank you.

Describe the issue

ln -s Äfoo.go afoo.go command fails, even though the file named Äfoo.go exists.

Steps to Reproduce the Problem

1. touch Äfoo.go
2. ln -s Äfoo.go afoo.go
3. The command fails with message "no such file or directory"

A symlink should be created instead.

Additional Context: Operating System, Screenshots

• OS: Windows 10 Pro 21H1 with October 2021 cumulative update

It also fails with cyrillic letters in file name, and I suspect it will fail with any non-ASCII letters.

Setting MSYS=winsymlinks:nativestrict is a workaround, no such error is raised then.

See msys2/MSYS2-packages#2128 (comment)

See msys2/msys2.github.io#152 (comment)

I submitted an issue on MSYS2-packages repo.
msys2/MSYS2-packages#2665

As I commented there, I submitted a bug report to cygwin mailing list.
https://cygwin.com/pipermail/cygwin/2021-November/249749.html

Now cygwin runtime is fixed.
cygwin/cygwin@561767f
cygwin/cygwin@2221beb
cygwin/cygwin@eb628ca

Since, this bug is found to be originated from msys2-runtime, I submit this issue here.

I request these patches to be ported to msys2.

Description

After the latest pacman update for the system, the cmake progress marks output appears garbled with duplicated characters, etc.. Almost like there is a code-page or encoding snafu. For example, after the latest updates on Win10, I see

[  8%] Built target bs2_default_padded_checksummed_asm
Consolidate compiler generated dependencies of target elf2uf2
Consolidate compiler generated dependencies of target pioasm
[100%] Built target elf2uf2
[100%] Built target pioasm
[[  1111%%]]  NoN oi nisntsatlall ls tsetpe pf ofro r' P'iEoLaFs2mUBFu2iBludi'ld
'
[ 13[% ]1 4%]C omCpolmeptleedt e'dP i'oEaLsFm2BUuFi2lBdu'il
d'
[[  2299%%]]  BBuuiilltt  ttaarrggeett  EPLiFo2aUsFm2BBuuiilldd

Scanning dependencies of target pwm_led_fade
Consolidate compiler generated dependencies of target pwm_led_fade
[ 31%] Linking CXX executable pwm_led_fade.elf
[100%] Built target pwm_led_fade

All text except the progress mark info (in some instances) appears fine.

I don't know what the issue may be, but after discovering it, I thought I would pass it along.

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

Windows 10
Version 21H2 (OS Build 10944.2130)

Expected behavior

I expected all compiler and cmake output to be readable without duplicated or garbled characters.

Actual behavior

Parts of the cmake output was unreadable with garbled and duplicated characters. For example, a very large part of the cmake output is gibberish:

[ 85[% ]8 6%[B] u 8i8l%Bd]ui inlgdB iuCni glo dbCij neogcb tjA eSCcMMt a okCbeMjFaieklceetFs i/ClpMewasmk/_eplFweimd
l__elfsea/dd_pefw.amdd_ielr.e/ddCi__rf//amCds_ey/.smd6si4yr/s/o6Cp4_t///omppsityc/sop6/i4pc/iooc/popt-i/scpdoik-c/so
sd/rkpc/i/scrropc-2/s_rdcpko2/m_smcroocnm//mrpopin2c/_opc_iofcmlomo_oafntl//opfailtco/oaf_tlf_oliaontai_ttm/_afrtolh
mo..acct.._oovbb1jj_

rom_shim.S.obj
[ 89%[]  9B1u%i]l diBnugi lCd [io nb9gj2 e%Ac]St M B CuoMibaljkdeeicFntig l CeAMsSa/Mkp ewoFmbi_jlleeecsdt/_ pfCwaMm
da_ekl.eedFdii_rlf/eaCsd_/e/p.mwdsmiy_rsl/6eC4d_/_/ofmpastdy/esp.6id4ci/oro//ppCti_/c/pomi-scsyods/k6p/4is/croocp-/t
sr/dppk2i/_cscoro/cmp/mirocpno2/-_pscidockmo/m_somrnac/l/plriopcc2o/__pcmioecmmom__oomnpa/slp/limocecom.__cso.tpoasb
n_jda
aeradb_il.iSn.ko/bcjr
t0.S.obj
[ 94%] Building CXX objec[t  9C5M%a]k eFBiulielsd/ipnwgm _Cl eodb_jfeacdte .CdMiark/eCF_i/lmessy/sp6w4m/_olpetd/_pfi
acdoe/.pdiicro/-Cs_d/km/ssyrsc6/4r/po2p_tc/opmimcoon//ppiiccoo[-_ ss9dt7ka%/n]sd racrB/dur_ipll2id_nickno/gmn meCow
n_o/dbpejilececott_e s.CtcMapanpkd.eaoFrbidjl_e
sl/ipnwkm/_blienda_rfya_dien.fdoi.rc/.Co_b/jm
sys64/opt/pico/pico-sdk/src/rp2_common/pico_stdio/stdio.c.obj
[ 98%] Building C object CMakeFiles/pwm_led_fade.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_stdio_uart/stdi
o_uart.c.obj
[100%] Linking CXX executable pwm_led_fade.elf

The packages installed that were updated today before the behavior appeared were:

 libnghttp2 (1.49.0-1 -> 1.50.0-1)
 libffi (3.4.2-1 -> 3.4.3-1)
 libgpg-error (1.45-2 -> 1.46-2)
 liblzma (5.2.6-1 -> 5.2.7-1)
 libsqlite (3.39.2-1 -> 3.39.4-1)
 libcurl (7.85.0-1 -> 7.85.0-2)
 curl (7.85.0-1 -> 7.85.0-2)
 file (5.42-2 -> 5.43-1)
 libexpat (2.4.8-2 -> 2.4.9-1)
 libfido2 (1.11.0-1 -> 1.12.0-1)
 perl-Net-SSLeay (1.90-1 -> 1.92-1)
 perl-IO-Socket-SSL (2.074-1 -> 2.075-1)
 git (2.37.3-1 -> 2.38.0-1)
 libgnutls (3.7.7-1 -> 3.7.8-1)
 libksba (1.6.0-2 -> 1.6.1-1)
 mingw-w64-x86_64-libwinpthread-git (10.0.0.r72.g1dd2a4993-1 -> 10.0.0.r113.g57fd0b77a-1)
 mingw-w64-x86_64-gcc-libs (12.2.0-1 -> 12.2.0-4)
 mingw-w64-x86_64-aom (3.4.0-1 -> 3.5.0-1)
 mingw-w64-x86_64-arm-none-eabi-binutils (2.38-1 -> 2.39-1)
 mingw-w64-x86_64-expat (2.4.8-1 -> 2.4.9-1)
 mingw-w64-x86_64-libffi (3.4.2-2 -> 3.4.3-1)
 mingw-w64-x86_64-zlib (1.2.12-1 -> 1.2.13-1)
 mingw-w64-x86_64-tcl (8.6.11-5 -> 8.6.12-1)
 mingw-w64-x86_64-tk (8.6.11.1-2 -> 8.6.12-1)
 mingw-w64-x86_64-xz (5.2.6-1 -> 5.2.7-1)
 mingw-w64-x86_64-python (3.10.6-1 -> 3.10.8-1)
 mingw-w64-x86_64-arm-none-eabi-gdb (9.2-5 -> 9.2-6)
 mingw-w64-x86_64-arm-none-eabi-newlib (3.3.0-1 -> 4.2.0.20211231-2)
 mingw-w64-x86_64-pkgconf (1.8.0-2 -> 1~1.8.0-2)
 mingw-w64-x86_64-libuv (1.42.0-3 -> 1.44.2-1)
 mingw-w64-x86_64-ninja (1.11.1-1 -> 1.11.1-2)
 mingw-w64-x86_64-libxml2 (2.9.14-4 -> 2.10.2-4)
 mingw-w64-x86_64-cmake (3.24.1-3 -> 3.24.2-3)
 mingw-w64-x86_64-headers-git (10.0.0.r72.g1dd2a4993-1 -> 10.0.0.r113.g57fd0b77a-1)
 mingw-w64-x86_64-crt-git (10.0.0.r72.g1dd2a4993-1 -> 10.0.0.r113.g57fd0b77a-1)
 mingw-w64-x86_64-extra-cmake-modules (5.97.0-1 -> 5.98.0-2)
 mingw-w64-x86_64-winpthreads-git (10.0.0.r72.g1dd2a4993-1 -> 10.0.0.r113.g57fd0b77a-1)
 mingw-w64-x86_64-gcc (12.2.0-1 -> 12.2.0-4)
 mingw-w64-x86_64-gcc-libgfortran (12.2.0-1 -> 12.2.0-4)
 mingw-w64-x86_64-gcc-fortran (12.2.0-1 -> 12.2.0-4)
 mingw-w64-x86_64-gdb (12.1-3 -> 12.1-4)
 mingw-w64-x86_64-gdb-multiarch (12.1-3 -> 12.1-4)
 mingw-w64-x86_64-libpng (1.6.37-6 -> 1.6.38-1)
 mingw-w64-x86_64-libheif (1.13.0-1 -> 1.13.0-2)
 xz (5.2.6-1 -> 5.2.7-1)
 pinentry (1.2.0-2 -> 1.2.1-1)
 pacman-contrib (1.6.0-1 -> 1.7.1-1)
 rsync (3.2.3-2 -> 3.2.6-1)
 tzcode (2022c-1 -> 2022d-1)

Not sure which if any are responsible.

Repro steps

On windows with the pico-SDK installed, pick any example program to compile. Create the out-of-source build dir, run cmake and then make.

Nothing more involved than that. I'm using Msys2 64 terminal, which is

mintty 3.6.1 (x86_64-pc-msys)[Windows 19044]

Are you willing to submit a PR?

I would if I had a clue which part may be involved. Can't help here.

Now winsymlink has following options to make soft links (ln -s 'file' 'target'):

• winsymlink:lnk: to make windows shortcut files
• winsymlink:native or winsymlink:nativestrict: to make windows symlinks (the same as mklink /d 'target' 'file')
• winsymlink: to copy the file of directory

But it is not possible to make windows junctions (mkdir /j 'target' 'file'), and that's not convenient, because only junctions support to make a symlink in a symlink directory.

So junction may need to be added to the options of winsymlinks

The last update resulted in all commands outputting a memory debug:

$ ls
      0 [main] bash (12028) shared_info::initialize: size of shared memory region changed from 57272 to 56248
                                                                                                                   0 [main] ls (9956) shared_info::initialize: size of shared memory region changed from 57272 to 56248
saved  work/

As we all know, most of the file systems on linux have this limitation.
On windows, the preset limit is 260 characters and it can be even more through modify registry value.

echo 'md "(エアコミケ4) (一般コミック) [这尼玛什么乱七八糟瞎起名坑爹作者] 名字起的这么长到底能有啥问题啊！这种几
十年前一拍脑袋就决定的东西今天看起来简直莫名其妙啊！为什么事情会变成这个样子呢？这种粗暴一刀切的限制在今天为什么还能存在啊"' > 1.bat && cmd < 1.bat
cd '(エアコミケ4) (一般コミック) [这尼玛什么乱七八糟瞎起名坑爹作者] 名字起的这么长到底能有啥问题啊！这种几十年前一拍脑袋就决定的东西今天看起来简直莫名其妙啊！为什么事情会变成这个样子呢？这种粗暴一刀切的限制在今天为什么还能存在啊'

cd: File name too long
cd: Unknown error trying to locate directory '(エアコミケ4) (一般コミック) [这尼玛什么乱七八糟瞎起名坑爹作者] 名字起的这么长到底能有啥问题啊！这种几十年前一拍脑袋就决定的东西今天看起来简直莫名其妙啊！为什么事情会变成这个样子呢？这种粗暴一刀切的限制在今天为什么还能存在啊'

Name of the created folder has 118 characters and 331 bytes, it is a valid windows folder name and most of MINGW64 tools can handle it correctly only if it was called from powershell or cmd

I was run ./config with prefix, and make install. I founded in prefix dir libc.a, libm.a, libg.a, but I need msys-2.0.dll. Where\How I must get it?

Thanks.

OS: Windows 10.

MSYS2 configuration:
I installed MSYS2 from https://www.msys2.org/, then opened a MSYS2 terminal window and ran

> pacman -Syu
> pacman -S base-devel gcc vim cmake git libcrypt-devel libreadline tree

Now I am debugging a C program from the MSYS2 terminal window using gdb. The C program calls dlopen() and when I step into the call with gdb I get:

(gdb) s
 _sigfe_dlopen () at sigfe.s:2652
2652    sigfe.s: No such file or directory.
(gdb) info source
Current source file is sigfe.s
Compilation directory is /msysdev/msys2-runtime/src/build-x86_64-pc-msys/x86_64-pc-msys/winsup/cygwin
Source language is asm.
Producer is GNU AS 2.34.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.

Note that it says compilation directory is /msysdev/msys2-runtime/src/build-x86_64-pc-msys/x86_64-pc-msys/winsup/cygwin but when I try to enter the directory from the MSYS2 terminal:

> ls /msysdev
ls: cannot access '/msysdev': No such file or directory

Any idea how I can get hold of the source files so I can debug this call to dlopen() ?

https://cygwin.com/git/?p=newlib-cygwin.git;a=shortlog;h=refs/heads/cygwin-3_3-branch

https://cygwin.com/pipermail/cygwin-announce/2021-October/010268.html

https://cygwin.com/pipermail/cygwin-announce/2021-October/010269.html

I have an issue with recent versions of MSYS2 that I didn't have with older versions.

I often paste a large number of commands, some of which are longer that the console width. There are also multiline commands in there (e.g. shell if stuff with the fi several lines later). But I do make sure there are no tabs in there to avoid autocompletion from kicking in.

In old MSYS2 I could just paste everything and the commands would start right away.

In newer MSYS2 after pasting it is apparently waiting for another Enter before starting.

But what's worse: the data pasted isn't intact. Sometimes pieces are missing, sometimes it gets truncated, sometimes both. I also noticed sometimes some part of the beginning of the clipboard is pasted at the end.

I have reproduced this on Windows 10 and Windows 11.

I tried running the shell via msys2.exe as well as others like mingw64.exe, and I even tried running sh.exe from ConsoleZ and from Windows Terminal in Windows 11.

I tried pasting from a different source (Notepad instead of Notepad++).

I tried changing the copied source (in Notepad++) to different line endings (CR, LF, CR+LF).

But the issue remains.

Is there some kind of setting or environment variable to get the old paste behaviour back?

I'm noticing an odd hang while trying to build libxml2 with MSYS + MinGW that I'm really struggling to dig into...

I'm using MSYS/MinGW within a Windows Docker container - place both of these files into a directory and build with Windows Docker Desktop using docker build -t test-image . while in said directory.
Dockerfile
mirrorupgrade.hook

Once I'm running that image as a container I'm doing:

cd /tmp
wget http://xmlsoft.org/download/libxml2-2.9.12.tar.gz
tar xf libxml2-2.9.12.tar.gz
cd libxml2-2.9.12
./configure --prefix=/usr/local
make -j4

The build reliably hangs trying to link:

  <snip>
  CCLD     testdso.la
  CCLD     libxml2.la
C:\tools\msys64\mingw64\bin\ar.exe: `u' modifier ignored since `D' is the default (see `U')

Here's output from a build using make V=1 instead in order to show the actual compilation commands:
make_output_libxml2.txt

I suspect the issue is something happening within libtool or is related to that warning message from ar when building non-verbosely - if I build libxml2 with CMake instead, everything works out fine. I've browsed the patches at https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libxml2, but none of them seem relevant to this failure mode - and I've seen a very similar failure mode happen in the same container while trying to build sqlite3 as well.

I'll note that building other Autotools packages on the same image - notably libffi, libyaml, and openssl seem to work fine.

Any ideas on what could be going on? I'm not sure how to proceed on debugging this further.

msys2 install by msys2-x86_64-20210725.exe on D:\msys2.
on vscode settings.json

{
    "terminal.integrated.profiles.windows": {
        "bash": {
            "path": "D:\\msys2\\usr\\bin\\bash.exe",
            "args": ["--login"]
        }
    },
    "terminal.integrated.defaultProfile.windows": "bash",
}

ctrl-c can't send signal correctly.

but change to git-windows it's normal(git 2.33.0.windows.2).

use msys2-runtime covered to git-windows will also appear.

Setup

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell iex(iwr -useb https://chocolatey.org/install.ps1)
RUN choco install msys2 -y  --params "/NoUpdate"

• Version

> rm --version
rm (GNU coreutils) 8.32

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue?

docker build -t msys-test .
docker run -it --rm -v c:\test msys-test
c:\>c:\tools\msys64\usr\bin\touch a

c:\>c:\tools\msys64\usr\bin\rm a

c:\>c:\tools\msys64\usr\bin\touch test\a

c:\>c:\tools\msys64\usr\bin\rm test\a
/usr/bin/rm: cannot remove 'test\a': Invalid argument

• What did you expect to occur after running these commands?

rm should delete the file

• What actually happened instead?

rm returns an error

See #40 -> msys2/MSYS2-packages#2471 (comment)

Upstream questions:

• https://cygwin.com/pipermail/cygwin/2021-May/248436.html
• https://cygwin.com/pipermail/cygwin/2021-May/248437.html

While debugging msys2/MSYS2-packages#3014 (comment) I found that trailing : has a different meaning and that the runtime just strips those (which is the root cause of the issue). I would expect the runtime to convert : to ; and leave it there at the end.

❯ TESTENV=/tmp/hello/world:/tmp/new: python -c 'import os; print(os.environ["TESTENV"])'
C:\msys64\tmp\hello\world;C:\msys64\tmp\new

I would expect the output to be C:\msys64\tmp\hello\world;C:\msys64\tmp\new;. Is it something that people would expect or can be treated as an expected behaviour? Does this break any use case?

should it force the issue with ExitProcess at all?

Hmm. I think your Python example points to the answer "no"... I had not thought about that.

Or somehow tell if the console control event was handled or not? (if that's possible)

I guess that the return value of CtrlRoutine would tell, but I am not sure. Since this function is undocumented, it will require some experimentation, methinks.

Originally posted by @dscho in #48 (comment)

https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/release/3.4.0;h=8337ba511e6496df1c92ffb718eeb7f1c0285402;hb=07a9a6c21ab34a7f392b679ded419cb4466b3009

Oddly enough, this hack seems to work:

diff --git a/winsup/utils/getprocaddr.c b/winsup/utils/getprocaddr.c
index 80b399c..beafc10 100644
--- a/winsup/utils/getprocaddr.c
+++ b/winsup/utils/getprocaddr.c
@@ -164,9 +164,9 @@ main (int argc, char **argv)
    * because here because that symbol isn't exported.
    */

-  if (strcmp (argv[1], "CtrlRoutine"))
+  if (TRUE || strcmp (argv[1], "CtrlRoutine"))
     {
-      HINSTANCE kernel32 = GetModuleHandle ("kernel32");
+      HINSTANCE kernel32 = GetModuleHandle (strcmp(argv[1], "CtrlRoutine") ? "kernel32" : "kernelbase");
       if (!kernel32)
         return 1;
       void *address = (void *)GetProcAddress (kernel32, argv[1]);

Maybe it could look in KERNELBASE for CtrlRoutine the same way it looks in KERNEL32 for ExitProcess, and if it's not found fall back to using dbghelp (assuming there's a downlevel version of Windows for which that didn't work, that prompted the dbghelp approach in the first place).

Originally posted by @jeremyd2019 in #47 (comment)

see msys2/MINGW-packages#7650

Simple reproducer,

• open minitty
• Install MinGW-python
• run python
• Press Ctrl+C
  traceback would be missing in minitty while the same is should when python is run in cmd

This cause the executable from setuptools, like pip.exe to not kill the child process as described msys2/MINGW-packages#7650

When discussing on Discord a few days ago, lazka pointed out that this is fixed in Git for Windows runtime.

The corresponding issue on Git for Windows: git-for-windows/git#1248
These are the patches:

• git-for-windows/msys2-runtime@e8dd881
• git-for-windows/msys2-runtime@24fb4e4
• git-for-windows/msys2-runtime@3c7a25e
• git-for-windows/msys2-runtime@0a1f55b

Hi, I apologize if this is the wrong place to post this issue.

I recently installed MSYS2 on my Windows 10 VM in VirtualBox, and I quickly found out that I can't navigate to any of my shared folders (which are mounted as Network Drives in Windows). The primary error message is Too many levels of symbolic links.

Here is some raw output from the shell:

$ cd /t
bash: cd: /t: Too many levels of symbolic links

$ df
df: /b: Too many levels of symbolic links
df: /g: Too many levels of symbolic links
df: /j: Too many levels of symbolic links
df: /p: Too many levels of symbolic links
df: /t: Too many levels of symbolic links
Filesystem        1K-blocks     Used Available Use% Mounted on
C:/Software/msys2  51849068 29908016  21941052  58% /
D:                    59642    59642         0 100% /d

Drive D is a CD-drive and I am able to access it normally, as well as the C drive (/c). All of my projects are on the host system so I need to access them via mechanisms such as shared folders, which are implemented as network drive mounts in VirtualBox's Windows guests.

I am able to use cmd and powershell normally in network drives as well as many other programs, this is one of the rare occasions where they have caused me trouble, I don't even recall the last issue I had with them.

We initially said that we'll enable it once there is a cygwin release without conpty fixes, but that hasn't happened.

Still it would be nice to have all those console using apps to just work by default.

@dscho could we try switching the default in this repo, or should we do it in a downstream patch first?

The MSYS2 runtime does some amount of interpretation of its own of the incoming command line string (which mostly is a feature, I guess). However the MSYS2 (or cygwin I presume) specific argument parsing breaks a number of details regarding how generic win32 processes parse their command line string.

The LLVM testsuite runs a large number of test cases, that involve invoking executables such as sed and grep, where the arguments may involve tricky strings with regexes and similar, where the exact escaping/unescaping of tricky characters is cruicial. The LLVM testsuite doesn't know if the sed or grep (or other shell utils) invoked are regular win32 executables (e.g. built with mingw, e.g. provided by the GnuWin tool suite) or MSYS2 based ones (in particular, LLVM's testsuite can automatically locate the set of tools installed as part of Git for Windows, as they generally fit the bill perfectly and often can be found installed on users' systems).

The LLVM tests have run into a number of cases where the regular win32 argument quoting/escaping rules don't work with MSYS based tools; some of the issues can be avoided by choosing a different quoting/escaping strategy, but overall there doesn't seem to be a single strategy that works consistently with both MSYS2 based tools and regular win32 based tools.

1. If one wants to pass the argument a"b to a regular win32 process, it is escaped as a\"b, which after argument parsing/unescaping gets parsed back into a"b. If a MSYS2 based process is passed a\"b, it receives a\b instead. This particular bug can be avoided by quoting the whole string instead; both win32 and MSYS2 based tools parse "a\"b" as a"b.

2. If one wants to pass the argument a[b\c to a regular win32 process, it doesn't need any extra escaping. If a MSYS2 based process is passed the argument a[b\c, the executable receives the argument a[bc. In this case, quoting the whole argument string, into "a[b\c" makes both win32 and MSYS2 based tools receive the same, expected argument.

3. If one wants to pass the argument a\b\\c\\\\d to a regular win32 process, it doesn't need any extra escaping either, and both win32 and MSYS2 based tools receive the same, the expected argument. However, if one quotes the whole argument (as a workaround to 1. or 2. above), the MSYS2 based tool receives a\b\c\\d instead, which wasn't what was intended.

4. As a separate workaround to 2. and 3. above, one can choose to instead set the env variable MSYS=noglob. That works around both issues 2. and 3., but breaks issue 1. above again, making both a\"b and "a\"b" be parsed as a\b instead of a\"b.

Or more consistently, here are the sets of inputs and parsed outputs:

So there doesn't seem to be any combination of quoting or setting MSYS=noglob that consistently reproduces what's expected (what the win32 equivalent app receives). By quoting case 1 and 3 into 4 and 6, but not quoting case 2, one can get something that works, but that's extremely brittle, as if case 2 requires quoting the argument for other reasons, it breaks again.

To reproduce, build a small test app like this with both the MSYS2 runtime and mingw, and try invoking it (e.g. from cmd.exe) with the various test input arguments:

#include <stdio.h>
int main(int argc, char **argv) {
    for (int i = 0; i < argc; i++)
        printf("%d: %s\n", i, argv[i]);
    return 0;
}

I presume this is mostly an upstream cygwin issue and there's not much you want to try to do about it at the MSYS2 level, but I thought I'd file it here first, for visibility and input, before proceeding further upstream.

POSIX requires that getcwd returns a path that "shall contain no components that are dot or dot-dot, or are symbolic links". This implies that symlinks in the current working directory need to be fully resolved in the path that getcwd returns.

Further, windows native symbolic directory links, created with mklink /d are treated as posix symlinks.

In my tests, it seems that if the last element of the current working directory is a symlink, then getcwd() does indeed return the path to the target directory. However, this is not done when one of the parent directories is a symlink.

Before attempting to fix it, I would like to verify that this is indeed a bug, and not a result of some compatibility calculus beyond my ken. Is this a bug?