Reportedly Windows 11 build 25*** from Insider changed the current
working directory logic a bit, and Cygwin's "magic" (or:
"technologically sufficiently advanced") code needs to be adjusted
accordingly.
This fixes https://github.com/git-for-windows/git/issues/4429
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
cpuid 0x00000007:0 ecx:7 shstk Shadow Stack support & Windows [20]20H1/[20]2004+
=> user_shstk User mode program Shadow Stack support
AMD SVM 0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
Sync AMD 0x80000008:0 ebx flags across two output locations
This solves redefinition of FILE_CS_FLAG_CASE_SENSITIVE_DIR in winnt.h
and fixes the following compiler errors
ntdll.h:523:3: error: expected identifier before numeric constant
523 | FILE_CS_FLAG_CASE_SENSITIVE_DIR = 0x01
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ntdll.h:522:1: note: to match this ‘{’
522 | {
| ^
When the @cjkwide and @cjksingle modifiers have been added, the
patches missed to add checks for the new modifiers in the Cygwin
locale code. Along the same lines, commit c3e7f7609e forgot to
add a test for @cjksingle.
Merge check for cjk* modifiers into a macro set andf use that
throughout. Fix comments.
Fixes: f92f048528 ("Locale modifier @cjkwide to adjust ambiguous-width in non-CJK locales")
Fixes: c8204b1069 ("Locale modifier "@cjksingle" to enforce single-width CJK width.")
Fixes: c3e7f7609e ("Cygwin: locales: fix behaviour for @cjk* and @euro locales")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Per the discussion starting with
https://cygwin.com/pipermail/cygwin/2023-April/253495.html
stop falling back to sh if the file given to posix_spawnp
is no executable.
This is not necessarily the last word on it, given
https://www.austingroupbugs.net/view.php?id=1674, but for now,
opt for following the proposal in the Austin Group bug entry,
as well as PASSing the GNULIB test-posix_spawnp-script test.
Fixes: c7c1a1ca1b ("Add support for new posix_spawn function.")
Fixes: 3fbfcd11fb ("Cygwin: posix_spawn: add Cygwin-specific code fixing process synchronisation")
Reported-by: Bruno Haible <bruno@clisp.org>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
mbrtowi was missing null-checks on pwi, but NULL is passed from
regex/engine.c:173.
In a git repo with sendemail.smtpserver set, this results in a segfault when
using git-send-email, which calls:
git config --get-regexp '^sende?mail[.]'
Fixes: 60c25da90d ("Cygwin: mbrtowi: define replacement for mbrtowc, returning UTF-32 value")
Signed-off-by: David McFarland <corngood@gmail.com>
In contrast to rename default behaviour, Linux' renameat2 returns -1
with errno set to EEXIST, if oldfile and newfile refer to the same
file, and the RENAME_NOREPLACE flag is set.
Follow suit, given this is a Linux-only function anyway.
Fixes: f665b1cef3 ("cygwin: Implement renameat2")
Reported-by: Bruno Haible <bruno@clisp.org>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
readlinkat(fd, "", ...) is supposed to return ENOENT per POSIX,
but Cygwin returns EBADF.
At the same time, we have to maintain the special feature of
glibc that readlinkat(fd, "", ...) operates on fd, if fd is pointing
at a symlink opened with O_PATH|O_NOFOLLOW.
And, while fixing that, readlinkat(fd, path, ...) *still* has to set errno
to EBADF, if fd is an invalid descriptor *and* path is a relative path.
This required to change the evaluation order in the helper function
gen_full_path_at.
Last but not least, in case of the aforementioned glibc-like special
handling for symlink descriptors, we have to make sure that errors from
gen_full_path_at are not spilled into that special handling.
Fixes: 6cc05784e1 ("Cygwin: readlinkat: allow pathname to be empty")
Reported-by: Bruno Haible <bruno@clisp.org>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2f9b8ff0 introduced a problem where forks would sometimes fail with:
child_copy: cygheap read copy failed, 0x0..0x80044C750, done 0, windows pid 14032, Win32 error 299
When cygheap_max was > CYGHEAP_STORAGE_INITIAL, commit_size would be set to
allocsize(cygheap_max), which is an address, not a size. VirtualAlloc would be
called to commit commit_size bytes, which would fail, and then child_copy would
be called with zero as the base address.
Fixes: 2f9b8ff00c ("Cygwin: decouple cygheap from Cygwin DLL")
Signed-off-by: David McFarland <corngood@gmail.com>
Previously, the pty master sends inputs to the pipe for cygwin app
even when pseudo console is activated if stdin is not the pty.
This causes the problem that key input is not sent to non cygwin
app even if the app opens CONIN$. This patch sets switch_to_nat_pipe
to true regardless whether stdin is the pty or not to allow that case.
https://cygwin.com/pipermail/cygwin/2023-April/253424.html
Reported-by: Wladislav Artsimovich <cygwin@frost.kiwi>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Preconditions of WSL or empty directories dependent on Windows
versions was totally screwed up. Drop the description from
--help, describe the preconditions for case-sensitive dirs in the
man page instead.
Fixes: fc6e89c937 ("Cygwin: chattr: clarify requirements for casesensitive directories")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
We should not blindly set the home directory of the SYSTEM account (or
of Microsoft accounts) to `/home/<name>`, especially
`/etc/nsswitch.conf` defines `db_home: env`, in which case we want to
respect the `HOME` variable.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Per https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/xbd_chap04.html:
"A pathname that begins with two successive slashes may be interpreted
in an implementation-defined manner, although more than two leading
slashes shall be treated as a single slash."
So more than 2 leading slashes are supposed to be folded into one,
which our dirname neglected. Fix that.
Fixes: 24e8fc6872 ("* cygwin.din (basename): Export.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch hails from Git for Windows (where the Cygwin runtime is used
in the form of a slightly modified MSYS2 runtime), where it is a
well-established technique to let the `$HOME` variable define where the
current user's home directory is, falling back to `$HOMEDRIVE$HOMEPATH`
and `$USERPROFILE`.
The idea is that we want to share user-specific settings between
programs, whether they be Cygwin, MSYS2 or not. Unfortunately, we
cannot blindly activate the "db_home: windows" setting because in some
setups, the user's home directory is set to a hidden directory via an
UNC path (\\share\some\hidden\folder$) -- something many programs
cannot handle correctly, e.g. `cmd.exe` and other native Windows
applications that users want to employ as Git helpers.
The established technique is to allow setting the user's home directory
via the environment variables mentioned above: `$HOMEDRIVE$HOMEPATH` or
`$USERPROFILE`. This has the additional advantage that it is much
faster than querying the Windows user database.
Of course this scheme needs to be opt-in. For that reason, it needs
to be activated explicitly via `db_home: env` in `/etc/nsswitch.conf`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
- Windows 10 requires WSL
- Windows 11 only allows enabling casesensitivity if dir is empty
Fixes: 0d4b39d37b ("Cygwin: Add lsattr and chattr tools")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Latest Windows supports more EU locales than GLibc, so some of the
@euro locales are not covered by checking the GLibc locale defaults.
Those locales have no long history, they are all UTF-8. So just
check for @euro in the UTF-8 case and set them to ISO-8859-15.
Fixes: 2483e54be8 ("Cygwin: locale: Set default charset from Linux locale -> codeset mapping")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
@cjknarrow and @cjkwide modifiers are newlib only, so they need
some tweaking in __set_charset_from_locale.
Fixes: 2483e54be8 ("Cygwin: locale: Set default charset from Linux locale -> codeset mapping")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Drop usage of newlocale/nl_langinfo_l/freelocale.
Call __set_charset_from_locale instead, and make sure to call it
with modifier, if any, otherwise suffer wrong results.
Fixes: c42b98bdc6 ("Cygwin: introduce /proc/codesets and /proc/locales")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
ResolveLocaleName does not simply return an error value if it
can't resolve a locale. Rather, it returns an empty string and
the length of this string: 1.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This reverts commit 15898b9588.
The idea behind this patch was wrong. Systems are supposed to
support iso639-only strings as settings for the locale environment
variables, and they are not necessarily available in the
/usr/share/locale/locale.alias file.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The Windows function ResolveLocaleName is next to useless to
convert a partial locale identifier into a full, supported
locale identifier. It converts anything which vaguely resembles
a locale into some other locale it supports.
Bad examples are:
"en-XY" gets converted to "en-US", and worse,
"ff-BF" gets converted to "ff-Latn-SN", even though "ff-Adlm-BF"
exists!
To check if a locale is supported, we have to enumerate all valid
Windows locales, and return the match, even if the locale in Windows
requires a script. Implement resolve_locale_name() as replacement
function for ResolveLocaleName.
Fixes: e95a7a7955 ("Cygwin: convert Windows locale handling from LCID to ISO5646 strings")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This was incorrect behaviour. The only valid way to support those
is by adding them to /usr/share/locale/locale.alias.
Fixes: e95a7a7955 ("Cygwin: convert Windows locale handling from LCID to ISO5646 strings")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This allows newlocale to return with a valid errno if the
locale is invalid.
Fixes: e95a7a7955 ("Cygwin: convert Windows locale handling from LCID to ISO5646 strings")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The sr_XY locales are supposed to default to cyrillic, but the code
always attached a @cyrillic, same reason as in the previous commit.
Special case "sr" further to workaround that issue.
Fixes: c42b98bdc6 ("Cygwin: introduce /proc/codesets and /proc/locales")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Due to the way locales are evaluated in Windows, we can't ask for
the script of the "sd-IN" locale, because Windows only knows the
"sd-Deva-IN" locale. So asking for the script of the "sd" locale
returns "Arab;", because "sd" is converted to "sd-Arab-PK".
Special case "sd-IN" to workaround that issue.
Fixes: c42b98bdc6 ("Cygwin: introduce /proc/codesets and /proc/locales")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Renaming files returns STATUS_INVALID_PARAMETE on a bind mounted file system
in hyper-v container with FILE_RENAME_POSIX_SEMANTICS.
Disable the use_posix_semantics flag and retry.
Signed-off-by: Yoshinao Muramatsu <ysno@ac.auone-net.jp>
Deleting files returns STATUS_INVALID_PARAMETE on a bind mounted file system
in hyper-v container with FILE_DISPOSITION_POSIX_SEMANTICS.
Therefore fall back to default method.
This code is suggested by Johannes Schindelin on github
and I change it more simple.
Signed-off-by: Yoshinao Muramatsu <ysno@ac.auone-net.jp>
If a host NTFS is mapped into a Hyper-V isolated container, the
OPEN_BY_FILE_ID filesystem flag is missing, just as if that NTFS
is a remote drive. However, NtQueryVolumeInformationFile claims
the drive is a local drive.
We can use this fact to learn that the process is running under
Hyper-V, and that the Hyper-V isolated process can't use rename/unlink
with POSIX semantics. Strange enough, the POSIX_UNLINK_RENAME filesystem
flag is still set...
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
These flags are used to check a remote filesystem. Not all
flags supported by a local NTFS are available when checking
a remote NTFS. Fix the flag set accordingly, otherwise
the remote NTFS will ba handled as CIFS.
Fixes: fcccdc4021 ("Cygwin: fs_info: update filesystem flags and check Windows 7 flags")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Except for the "C" or "POSIX" locale, checking for start <= finish
is always wrong. Range start must be <= range finish in terms of the
locale's collating order. So make sure to call always wcscoll(), even
in the "C"/"POSIX" locale, which makes wcscoll equivalent to wcscmp
anyway.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
computejumps() moves g->charjump to a position relativ to the value of
CHAR_MIN. As such, g->charjump doesn't necessarily point to the address
actually allocated. While regfree() takes that into account, the low
memory handling in regcomp_internal() doesn't. Fix that by free'ing
the actually allocated address, as in regfree().
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Useless indirection. Rename _unlink_nt back to unlink_nt
and call the function directly with `sharable' flag as needed.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Update the list of filesystem flags to the flags supported since
Windows 7. Make sure to use the new flags only with Windows
filesystems, not with 3rd party filesystems.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
wint_t is unsigned int and the test checks for a negative value. Thus,
it's optimized out by gcc. Add the cast from commit 44caccfca2 to
avoid this.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
...and use __wcollate_range_cmp. This will have to be tweaked further
when supporting collation symbols...
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Don't print all RT signals, just the allowed patterns
- Add -L/--table option to print a table of signals with signal
numbers
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Johannes Schindelin
Brian Inglis
Biswapriyo Nath
Jon Turney
Corinna Vinschen
David McFarland
Takashi Yano
Yoshinao Muramatsu