Existing issues matching what you're seeing
Git for Windows version
git version v2.54.0.windows.1
cpu: x86_64
built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c
sizeof-long: 4
sizeof-size_t: 8
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Enabled
Enable Builtin Interactive Add: Enabled
Other interesting things
No.
Terminal/shell
Bash
Commands that trigger the issue
Expected behaviour
The contents of the current directory is initially empty, a new file is created programmatically via:
#include <stdio.h>
int main()
{
wchar_t name[] = L"A.txt";
name[0] = 0xD805;
_wfopen(name, L"w");
}
When git-bash is used to run the command /bin/cat * the expected output should be empty - the empty contents of the text file and the command should return the exit status zero.
Actual behaviour
cat * 2>&1
cat: 㮳.txt: No such file or directory
in detail:
cat * 2>&1 | xxd -g 1
00000000: 63 61 74 3a 20 e3 ae b3 2e 74 78 74 3a 20 4e 6f cat: ....txt: No
00000010: 20 73 75 63 68 20 66 69 6c 65 20 6f 72 20 64 69 such file or di
00000020: 72 65 63 74 6f 72 79 0a rectory.
Observing the command with Procmon from sysinternals shows the wrong filename that is accessed, here that file doesn't exist so we get an error. If that file existed then it would be opened erroneously.
Repository
No response
Existing issues matching what you're seeing
Git for Windows version
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
cat /etc/install-options.txt Editor Option: VIM Custom Editor Path: Path Option: Cmd SSH Option: OpenSSH Tortoise Option: false CURL Option: OpenSSL CRLF Option: CRLFAlways Bash Terminal Option: MinTTY Performance Tweaks FSCache: Enabled Use Credential Manager: Disabled Enable Symlinks: Enabled Enable Builtin Interactive Add: EnabledOther interesting things
No.
Terminal/shell
Bash
Commands that trigger the issue
/bin/cat *Expected behaviour
The contents of the current directory is initially empty, a new file is created programmatically via:
When git-bash is used to run the command
/bin/cat *the expected output should be empty - the empty contents of the text file and the command should return the exit status zero.Actual behaviour
in detail:
Observing the command with Procmon from sysinternals shows the wrong filename that is accessed, here that file doesn't exist so we get an error. If that file existed then it would be opened erroneously.
Repository
No response