Signed-off-by: Corinna Vinschen <corinna@vinschen.de>

…own to fail

LookupAccountSid might take a long time if an SID cannot be resolved.
While we know some SIDs never resolved by LookupAccountSid, we call it
anyway and only handle them after it returned with error.

(Partially?) fix this latency problem by skipping the LookupAccountSid
call for SID groups never resolved anyway.

Reported-by: Lluís Batlle i Rossell <viric@viric.name>
Fixes: 1ca20a1 ("Introduce reading passwd/group entries from SAM/AD.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
(cherry picked from commit 008a02bc722569fc492b757a2cb2f6ef1c17a6a3)

For a datagram socket received by recvfrom, the type param is not
assigned correctly, making fhandler_socket_local::connect() to return
WSAEPROTOTYPE.

Fixes: 2617a91 ("* fhandler_socket.cc (get_inet_addr): Handle abstract AF_LOCAL socket.")
Signed-off-by: Yuyi Wang <Strawberry_Str@hotmail.com>
(cherry picked from commit 3b06366)

Due to a bug introduced by the commit 3312f2d, when the parent
process exits before the child process exits, disable_master_thread
is wrongly set to true, that disables special key handling such as
Ctrl-C. With this patch, the disable_master_thread is set to true if
any of the following conditions is met.
  - The parent process is not a cygwin process.
  - The master process already died.
  - The current process is the master process.
Otherwise, disable_master_thread remains false to keep special key
handling enabled.

Addresses: https://cygwin.com/pipermail/cygwin/2025-April/257909.html
Fixed: 3312f2d ("Cygwin: console: Redesign mode set strategy on close().")
Reported-by: Jeremy Drake <cygwin@jdrake.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>

Addresses: https://sourceware.org/pipermail/cygwin-patches/2025q2/013644.html
Fixes: 3e8a7eb ("sys/unistd.h: fix definition of setproctitle_init")
Reported-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Co-authored-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 1c530c3)

Don't try to change the file attributes for devices, e.g. /dev/null,
this can lead to confusion later.

Addresse: https://cygwin.com/pipermail/cygwin/2025-April/257940.html
Fixes: 2d81f6e ("Cygwin: open: always fix up cached DOS file attributes after NtCreateFile")
Reported-by: Bruno Haible <bruno@clisp.org>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 37c49de)

The DL_info::dli_fname member is actually PATH_MAX bytes, so specify
that (larger) size to cygwin_conv_path rather than MAX_PATH.

Also, use a tmp_pathbuf for the GetModuleFileNameW buffer, so that any
buffer size limitation will definitely be due to the size of dli_fname,
and add a static_assert of the size of dli_fname so we can be sure we're
using the right size constant here.

Fixes: c8432a0 ("Implement dladdr() (partially)")
Addresses: rust-lang/backtrace-rs#704 (comment)
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
(cherry picked from commit 38772dd)

... Otherwise, the opportunity for cleanup the wakeup event handle etc.
may be lost because the user signal handler never returns if it calls
longjmp(). This results in handle leak because the wakeup event handle
will not be closed. This issue happens when the commnad e.g. "stress-ng
--mprotect 1 -t 5" is executed. Instead, call call_signal_handler()
after cleaning up if some signals are armed during waiting wakeup event.
This essentially reverts the commit d243e51, however, the deadlock
fixed by that commit no longer occurs even reverting it for some reason.
This is probably due to the redesign of the signal queue.

In addition, do not touch "incyg" flag in _cygtls::call_signal_handler()
because the process is still in the cygwin function when a user signal
handler is called from the cygwin functions such as cygwait().

Addresses: https://sourceware.org/pipermail/cygwin/2025-March/257726.html
Fixes: d243e51 ("Cygwin: signal: Fix deadlock between main thread and sig thread")
Fixes: 3a1ccfc ("* exceptions.cc (setup_handler): Remove locked flag.  Use 'incyg' flag and in_exception function to determine when we're in a cygwin function.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 68991cd)

... because cygserver-config no longer works due to the behaviour
change of -f option in 'ps'.

Addresses: https://cygwin.com/pipermail/cygwin/2025-April/258086.html
Fixes: 1ce9756 ("Cygwin: ps -f: output command line")
Reported-by: Christian Lupien <Christian.Lupien@USherbrooke.ca>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>

Add type posix_tnode.  Change certain uses of "void" to "posix_tnode" in
both the prototypes and definitions of functions associated with <search.h>.

(Necessary changes to Newlib's /libc/include/search.h have already been
submitted in a patch sent to newlib@sourceware.org.)

Reported-by: Collin Funk <collin.funk1@gmail.com>
Addresses: https://cygwin.com/pipermail/cygwin/2025-April/258032.html
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Fixes: ec98d19 "* wininfo.h (wininfo::timer_active): Delete."
(cherry picked from commit e6b915d)

Add type posix_tnode.  Change certain uses of "void" to "posix_tnode" in
both the prototypes and definitions of functions associated with <search.h>.

(Necessary changes to Cygwin's /usr/include/search.h will follow in a
separate patch to be sent to cygwin-patches.)

Reported-by: Collin Funk <collin.funk1@gmail.com>
Addresses: https://cygwin.com/pipermail/cygwin/2025-April/258032.html
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Fixes: ec98d19 "* wininfo.h (wininfo::timer_active): Delete."
(cherry picked from commit 65d7818)

In the CCP_POSIX_TO_WIN_W path, when `from` is a device,
cygwin_conv_path would attempt to write to the `to` buffer before the
validation of the `size`.  This resulted in an EFAULT error in the
common use-case of passing `to` as NULL and `size` as 0 to get the
required size of `to` for the conversion (as used in
cygwin_create_path).  Instead, set a boolean and write to `to`
after validation.

Fixes: 43f65cd ("* Makefile.in (DLL_OFILES): Add fhandler_procsys.o.")
Addresses: https://cygwin.com/pipermail/cygwin/2025-April/258068.html
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
(cherry picked from commit 5dd3d58)

Seems to be needed now fedora-latest is F42.

(cherry picked from commit 6ef7bd5)

The commit 68991cd dropped toggling incyg flag in the function
call_signal_handler(). However this seems to cause another problem
that the command "stress-ng --kill 0 -t 5" sometimes leaves child
processes hanging. With this patch additional mechanism to determin
whether the target thread is inside cygwin1.dll has been introduced
instead. This mechanism utilizes _cygtls::inside_kernel() function
with additional argument to return true if the code is in the cygwin
DLL even if incyg flag is not set.

Fixes: 68991cd ("Cygwin: signal: Do not handle signals while waiting for wakeup evt")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit b7097ab)

Explicitly specify that `from` and `to` are NUL-terminated strings, that
NULL is permitted in `to` when `size` is 0, and that `to` is not
written to in the event of an error (unless it was a fault while writing
to `to`).

Signed-off-by: Jeremy Drake <cygwin@jdrake.com>

Signed-off-by: Jeremy Drake <cygwin@jdrake.com>

... and restore it when app exits. The commit 0bfd91d has a bug
that the console mode is stored into the shared memory when both:
  (1) cygwin process is started from non-cygwin process.
  (2) cygwin process started from non-cygwin process exits.
(1) is intended, but (2) is not. Due to (2), the stored console mode
is unexpectedly broken when the cygwin process exits. Then the mode
restored will be not as expected. This causes undesired console mode
in the use case that cygwin and non-cygwin apps are mixed.

With this patch, the console mode will stored only in the case (1).
This is done by putting the code, which stores the console mode, into
fhandler_console::open() rather than fhandler_console::set_input_mode()
and fhandler_console::set_output_mode().

Fixes: 0bfd91d ("Cygwin: console: tty::restore really restores the previous mode")
Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 09ae9f6)

In the commit 0bfd91d, the behaviour of the tty::restore was
changed so that the console mode is set to the previouslly stored
console mode. Therefore, the console mode for the background non-
cygwin app should not be set to tty::restore anymore in setup_for_
non_cygwin_app(). This should have been fixed in that commit.
This patch belatedly fixes it.

Fixes: 0bfd91d ("Cygwin: console: tty::restore really restores the previous mode")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 854150f)

Currently, opening both side of fifo in a process hangs if the
read side is opened first. The following test case exhibit the
hang while it works in linux.

  #include <unistd.h>
  #include <pthread.h>
  #include <sys/stat.h>
  #include <fcntl.h>

  #define fifo1 "/tmp/fifo-test"

  void *thr1(void *)
  {
    int fd;
    usleep(100000);
    fd = open(fifo1, O_WRONLY);
    write(fd, "A", 1);
    usleep(100000);
    close(fd);
    return NULL;
  }

  int main()
  {
    int fd;
    pthread_t th;
    char c;
    mkfifo(fifo1, 0600);
    pthread_create(&th, NULL, thr1, NULL);
    fd = open(fifo1, O_RDONLY);
    pthread_join(th, NULL);
    read(fd, &c, 1);
    write(1, &c, 1);
    close(fd);
    unlink(fifo1);
    return 0;
  }

The mechanism of hang is as follows. The main thread tries to open
the fifo for reading, but fhandler_fifo::open blocks until it detects
that someone is opening the fifo for writing. The other thread wants
to do that, but it never gets to the point of calling fhandler_fifo::
open because it is stuck waiting for the lock on cygheap->fdtab.

To fix this, this patch delays the construction of the cygheap_fdnew
object fd until after fhandler_fifo::open has been called.

Fixes: df63bd4 ("* cygheap.h (cygheap_fdmanip): New class: simplifies locking and retrieval of fds from cygheap->fdtab.")
Reviewd-by: Ken Brown <kbrown@cornell.edu>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit cec8a66)

…ugger

This fixes constantly replaying the exception if we have a segfault
while a debugger is already attached, e.g. stracing a segv, see:

https://cygwin.com/pipermail/cygwin/2025-May/258144.html

Future work:

The 'debugging' static in exception::handle(), which makes us replay the
exception the next half a million times it's hit seems like cruft, maybe
we should look at if it's possible to remove that?

Fixes: 9145737 ("Cygwin: Make 'ulimit -c' control writing a coredump")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
(cherry picked from commit b39b510)

The RegionSize member of the MEMORY_BASIC_INFORMATION struct is of type
SIZE_T, and it may be larger than will fit in a DWORD (I observed
0x200000000).  This resulted in an error due to trying to reserve 0
bytes from VirtualAllloc.

Fixes: 8d777a1 ("* dll_init.cc (reserve_at, release_at): New functions.")
Addresses: https://cygwin.com/pipermail/cygwin/2025-May/258154.html
Reported-by: Yuyi Wang <Strawberry_Str@hotmail.com>
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>

Cygwin's speclib doesn't handle dashes or dots. However, we are about to
rename the output file name from `cygwin1.dll` to `msys-2.0.dll`.

Let's preemptively fix up all the import libraries that would link
against `msys_2_0.dll` to correctly link against `msys-2.0.dll` instead.

…ent variables to Windows form for native Win32 applications.

…les.

…t without ACLs. - Can read /etc/fstab with short mount point format.

The new `winsymlinks` mode `deepcopy` (which is made the default) lets
calls to `symlink()` create (deep) copies of the source file/directory.

This is necessary because unlike Cygwin, MSYS2 does not try to be its
own little ecosystem that lives its life separate from regular Win32
programs: the latter have _no idea_ about Cygwin-emulated symbolic links
(i.e. system files whose contents start with `!<symlink>\xff\xfe` and
the remainder consists of the NUL-terminated, UTF-16LE-encoded symlink
target).

To support Cygwin-style symlinks, the new mode `sysfile` is introduced.

Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Co-authored-by: Jeremy Drake <github@jdrake.com>

This commit starts the rebase of 282740c to 2706b9d9f9

Seeing as Git for Windows tries to stay close to the upstream MSYS2
project, it makes sense to integrate their patches verbatim.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Even when the character set is specified as ASCII, we should handle data
outside the 7-bit range gracefully by simply copying it, even if it is
technically no longer ASCII.

This fixes several of Git for Windows' tests, e.g. t7400.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v2...v4)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

It came in real handy while debugging an issue that strace 'fixed'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot#enabling-dependabot-version-updates-for-actions for details.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

	* dcrt0.cc (dll_crt0_1), dtable.cc (handle_to_fn), environ.cc
	(environ_init, getwinenveq, build_env), external.cc
	(fillout_pinfo), fhandler_disk_file.cc (__DIR_mounts::eval_ino,
	fhandler_disk_file::readdir_helper), fhandler_netdrive.cc
	(fhandler_netdrive::readdir), fhandler_process.cc
	(format_process_winexename, format_process_maps,
	format_process_stat, format_process_status), fhandler_procsys.cc
	(fill_filebuf, fhandler_procsys::readdir), mount.cc
	(fs_info::update, mount_info::create_root_entry,
	mount_info::conv_to_posix_path, mount_info::from_fstab_line),
	nlsfuncs.cc (internal_setlocale), path.cc (path_conv::check,
	sysmlink_info::check_shortcut, symlink_info::check_sysfile,
	symlink_info::check_reparse_point,
	symlink_info::check_nfs_symlink, cygwin_conv_path,
	cygwin_conv_path_list, cwdstuff::get_error_desc, cwdstuff::get),
	strfuncs.cc (sys_wcstombs_no_path, sys_wcstombs_alloc_no_path),
	uinfo.cc (ontherange, fetch_from_path, cygheap_pwdgrp::get_home,
	cygheap_pwdgrp::get_shell, cygheap_pwdgrp::get_gecos), wchar.h
	(sys_wcstombs_no_path, sys_wcstombs_alloc_no_path): Convert call
	sites of the sys_wcstombs*() family to specify explicitly when the
	parameter refers to a path or file name, to avoid future
	misconversions.

Detailed explanation:

The sys_wcstombs() function contains special handling for paths/file
names, to work around file name restriction on Windows that are
unexpected in the POSIX context of Cygwin.

We actually do not want that special handling for WCS strings that
do *not* refer to paths or file names.

Neither do we want to convert those special file names unless they come
from inside Cygwin: if the source of the string value is the Windows API,
we *know* it cannot be such a special file name because Windows itself
would not be able to handle it in the way Cygwin does.

So let's switch the previous sys_wcstombs()/sys_wcstombs_no_path() (and
the *_alloc* variant) around to sys_wcstombs_path()/sys_wcstombs(). We do
this for several reasons:

- whenever a call site wants to convert a WCS representation of a path or
  file name to an MBS one, it should be made very clear that we *want* the
  special file name conversion to happen.

- it is shorter to read and write.

- future calls to sys_wcstombs() will not incur unwanted conversion by
  accident (it is easy for unsuspecting programmers to assume that the
  function name "sys_wcstombs()" refers to a regular text conversion that
  has nothing to do with paths or filenames).

By keeping the name sys_wcstombs() (and not switching to
sys_wcstombs_path()), the following call sites are implicitly changed to
*exclude* the special path/file name conversion:

cygheap.h (get_drive):
	Cannot contain special characters

external.cc (cygwin_internal):
	Refers to user/domain names, not paths

fhandler_clipboard.cc (fhandler_dev_clipboard::read):
	Is not a path or file name but characters from the Windows
	clipboard

fhandler_console.cc: (dev_console::con_to_str):
	Is not a path or file name but characters from the console

fhandler_registry.cc (encode_regname):
	Is a registry key, not a path or filename

fhandler_registry.cc (multi_wcstombs):
	All call sites pass registry values, not paths or filenames

fhandler_registry.cc (fstat):
	Is a registry value, not a path or filename

fhandler_registry.cc (fill_filebuf):
	Is a registry value, not a path or filename

net.cc (get_ipv4fromreg):
	Is a registry value, not a path or filename

net.cc (get_friendlyname):
	Is a device name, not a path or filename

netdb.cc (open_system_file):
	Is from outside Cygwin

smallprint.cc (__small_vsprintf):
	Is a free text, not a path or filename

strfuncs.cc (strlwr):
	Should preserve the characters from the private page if there
	are any

strfuncs.cc (strupr):
	Should preserve the characters from the private page if there
	are any

uinfo.cc (cygheap_user::init):
	Refers to a user name, not a path or filename

uinfo.cc (pwdgrp::fetch_account_from_windows):
	Refers to value from outside Cygwin

By keeping the function name sys_wcstombs_alloc() (and not changing it to
sys_wcstombs_alloc_path()), the following call sites are implicitly
changed to *exclude* the special path/file name conversion:

ldap.cc (cyg_ldap::remap_uid):
	Refers to a user name, not a path or filename

ldap.cc (cyg_ldap::remap_gid):
	Refers to a group name, not a path or filename

pinfo.cc (_pinfo::cmdline):
	Refers to a command line from Windows, outside Cygwin

uinfo.cc (cygheap_user::env_logsrv):
	Is a server name, not a path or filename

uinfo.cc (cygheap_user::env_domain):
	Refers to the user/domain name, not a path or filename

uinfo.cc (cygheap_user::env_userprofile):
	Refers to Windows' idea of a path, outside Cygwin

uinfo.cc (cygheap_user::env_systemroot):
	Refers to Windows' idea of a path, outside Cygwin

uinfo.cc (fetch_from_description):
	Refers to values from outside of Cygwin

uinfo.cc (cygheap_pwdgrp::get_gecos):
	Refers to user/domain name and email address, not path nor filename

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When a non ascii char is at the beginning of a path the current conversion
destroys the path. This fix will prevent this with an extra check for
non-ascii UTF-8 characters.

Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: 마누엘 <nalla@hamal.uberspace.de>

This is a forked repository...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Windows native symlinks must match the type of their target (file or
directory), otherwise native Windows tools will fail. Creating symlinks in
'nativestrict' mode currently requires the target to exist in order to
check its type.

However, the target of a symlink can change at any time after the symlink
has been created. Thus users of native symlinks must be prepared to deal
with type mismatches anyway. Checking the target type at symlink creation
time is not a good reason to violate the symlink() API specification.

In 'nativestrict' mode, always create native symlinks. Choose the symlink
type according to the target if it exists. Otherwise check the target path
for a trailing '/' as hint to create a directory symlink.

This allows callers to explicitly specify the expected target type, e.g.:

  $ ln -s test/ link-to-test
  $ mkdir test

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Internally, Cygwin already uses __utf8_mbtowc(), even if it still claims
to use the "ASCII" charset.

But the `MB_CUR_MAX` value (which is not actually a constant, but
dependent on the current locale) was still 1, which broke the initial
`globify()` call while parsing the the command-line in `build_argv()`
for non-ASCII arguments.

This fixes git-for-windows/git#2189

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This might break things, but it turns out several Windows libraries like
to be loaded at 0x180000000.

This causes a problem, because `msys-2.0.dll` loads at `0x180040000` and
expects `0x180000000-0x180040000` to be available. A problem arises when
Antiviruses (or other DLL hooking mechanisms) load a DLL whose preferred
load address is `0x180000000` and fits in size before `0x180010000`:

1. `msys-2.0.dll` loads and fills `0x180010000-0x180040000` assuming no
   shared console structure is going to be needed.

2. Another DLL loads and fills `0x180000000-0x18000xxxx`

3. `msys-2.0.dll` tries to load `0x180000000-0x180010000` but it's not
   available. It falls back to another address, but down the line
   something else fails.

This bug triggers when using subshells (e.g.: `git clone --recursive`).

The MSYS2 runtime should be able to work around the address conflict,
but the code is failing in some way or other...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Mikael Larsson <95430516+chirpnot@users.noreply.github.com>

Commit a5bcfe6 removed an optimization that fetches the
default group from the current user token, as it is sometimes
not accurate such as when groups like the builtin
Administrators group is the primary group.

However, removing this optimization causes extremely poor
performance when connected to some Active Directory
environments.

Restored this optimization as the default behaviour, and
added a `group: db-accurate` option to `nsswitch.conf` that
can be used to disable the optimization in cases where
accurate group information is required.

This fixes git-for-windows/git#4459

Signed-off-by: Richard Glidden <richard@glidden.org>

One particularly important part of Git for Windows' MSYS2 runtime is
that it is used to run Git's tests, and regressions happened there: For
example, the first iteration of MSYS2 runtime v3.5.5 caused plenty of
hangs. This was realized unfortunately only after deploying the
msys2-runtime Pacman package, and some painful vacation-time scrambling
was required to revert to v3.5.4.This was realized unfortunately only
after deploying the msys2-runtime Pacman package, and some painful
vacation-time scrambling was required to revert to v3.5.4.

To verify that this does not happen anymore, let's reuse what
`setup-git-for-windows-sdk` uses in Git's very own CI:

- determine the latest successful `ci-artifacts` workflow run in
  git-for-windows/git-sdk-64

- download its Git files and build artifacts

- download its minimal-sdk

- overwrite the MSYS2 runtime in the minimal-sdk

- run the test suite and the assorted validations just like the
  `ci-artifacts` workflow (from which these jobs are copied)

This obviously adds a hefty time penalty (around 7 minutes!) to every
MSYS2 runtime PR in the git-for-windows org. Happily, these days we
don't need many of those, and the balance between things like the v3.5.5
scramble and waiting a little longer for the CI to finish is clearly in
favor of the latter.

Co-authored-by: Jeremy Drake <github@jdrake.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Assorted fixes for Git for windows

Allow native symlinks to non-existing targets in 'nativestrict' mode

This topic branch fixes the problem where a UTF-16 command-line was
converted to UTF-8 in an incorrect way (because Cygwin treated it as if
it was a file name and applied some magic that is intended to allow for
otherwise invalid file names on Windows).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Workaround certain anti-malware programs

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

msys2-runtime: restore fast path for current user primary group

ci: run Git's entire test suite

The issue reported in microsoft/git#730 was
fixed, but due to missing tests for the issue a regression slipped in
within mere weeks.

Let's add an integration test that will (hopefully) prevent this issue
from regressing again.

This integration test is implement as an AutoHotKey script. It might
look unnatural to use a script language designed to implement global
keyboard shortcuts, but it is a quite powerful approach. While
there are miles between the ease of developing AutoHotKey scripts and
developing, say, Playwright tests, there is a decent integration into VS
Code (including single-step debugging), and AutoHotKey's own development
and community are quite vibrant and friendly.

I had looked at alternatives to AutoHotKey, such as WinAppDriver,
SikuliX, nut.js and AutoIt, in particular searching for a solution that
would have a powerful recording feature similar to Playwright, but did
not find any that is 1) mature, 2) well-maintained, 3) open source and
4) would be easy to integrate into a GitHub workflow. In the end,
AutoHotKey appeared my clearest preference.

So how is the test implemented? It lives in `ui-test/` and requires
AutoHotKey v2 as well as Windows Terminal (the Legacy Prompt would not
reproduce the problem). It then follows the reproducer I gave to the
Cygwin team:

1. initialize a Git repository
2. install a `pre-commit` hook
3. this hook shall spawn a non-Cygwin/MSYS2 process in the background
4. that background process shall print to the console after Git exits
5. open a Command Prompt in Windows Terminal
6. run `git commit`
7. wait until the background process is done printing
8. press the Cursor Up key
9. observe that the Command Prompt does not react (in the test, it
   _does_ expect a reaction: the previous command in the command
   history should be shown, i.e. `git commit`)

In my reproducer, I then also suggested to press the Enter key and to
observe that now the "More ?" prompt is shown, but no input is accepted,
until Ctrl+Z is pressed. Naturally, the test should not expect _that_
;-)

There were a couple of complications I needed to face when developing
this test:

- I did not find any easy macro recorder for AutoHotKey that I liked. It
  would not have helped much, anyway, because intentions are hard to
  record.

- Before I realized that there is excellent AutoHotKey support in VS
  Code via the AutoHotKey++ and AutoHotKey Debug extensions, I struggled
  quite a bit to get the syntax right.

- Windows Terminal does not use classical Win32 controls that AutoHotKey
  knows well. In particular, there is no easy way to capture the text
  that is shown in the Terminal. I tried the (pretty excellent!) [OCR
  for AutoHotKey](https://github.com/Descolada/OCR), but it uses UWP OCR
  which does not recognize constructs like "C:\Users\runneradmin>"
  because it is not English (or any other human language). I ended up
  with a pretty inelegant method of selecting the text via mouse
  movements and then copying that into the clipboard. This stops
  scrolling and I worked around that by emulating the mouse wheel
  afterwards.

- Since Windows Terminal does not use classical Win32 controls, it is
  relatively hard to get to the exact bounding box of the text, as there
  is no convenient way to determine the size of the title bar or the
  amount of padding around the text. I ended up hard-coding those
  values, I'm not proud of that, but at least it works.

- Despite my expectations, `ExitApp` would not actually exit AutoHotKey
  before the spawned process exits and/or the associated window is
  closed.

For good measure, run this test both on windows-2022 (corresponding to
Windows 10) and on windows-2025 (corresponding to Windows 11).

Co-authored-by: Eu-Pin Tien <eu-pin.tien@diamond.ac.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Converted ui-tests workflow into a test matrix that uses both the windows-2022 and windows-2025 runners.

…blem

Re-fix the Git hooks problem