Git for Windows Bash(not git): Start a process when its path is a symbolic link, the Argv0 of the process is incorrect

[fcharlie]

This issue is related to the Git for Windows Bash environment and has nothing to do with Git

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.21.0.windows.1
cpu: x86_64
built from commit: 2481c4cbe949856f270a3ee80c802f5dd89381aa
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [版本 10.0.18362.53]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

Details

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

Git Bash

When I started a program in the Git-for-Windows Bash environment that had a path as a symbolic link, it passed the wrong Arg0. Before calling CreateProcess, Arg0 is resolved directly to the reparsepoint of the symbolic link, at which point the Argv0 of the process created is not consistent with the requirements.

For example:

We can create a C++ program like follow:

/// argv0.cc
#include <clocale>
#include <cstdio>
#include <cstdlib>

int wmain(int argc, wchar_t **argv) {
  _wsetlocale(LC_ALL, L"");
  for (int i = 0; i < argc; i++) {
    wprintf(L"%d: %s\n", i, argv[i]);
  }
  return 0;
}

cd /d %TEMP%
mkdir symlink
cd symlink
:: edit the source code in this directory
cl argv0.cc
mklink argv_symlink.exe %CD%\argv0.exe

CMD output:

:: .\argv_symlink.exe "hello world"
0: .\argv_symlink.exe
1: hello world

MSYS2 output:

#$ ./argv_symlink.exe  "hello world"
0: D:\AppData\Local\Temp\symlink\argv_symlink.exe
1: hello world

Git Bash output:

#$ ./argv_symlink.exe "hello world"
0: D:\AppData\Local\Temp\symlink\arg0.exe
1: hello world

[PhilipOakley]

There is current work at #1561. I'll close this report and you can participate in on-going work at #1561.

[fcharlie]

@PhilipOakley This is not the same problem. It is actually not related to git, but to the MSYS2 Bash environment that Git for Windows carries. This issue has been fixed in the official release of MSYS2, and it still exists in Git for Windows Bash.

The essence of this problem is that when the started process path is a symbolic link, it is incorrectly changed to start directly from the target path of the symbolic link, causing Argv0 to be different from expected, and on Windows systems, it may also cause dll loading path. Not in line with expectations.

[fcharlie]

@dscho This issue is related to Cygwin (msys2-runtime) or Bash.

[PhilipOakley]

Have a look into the build-extra repo which contains all the bash and other support items to see if this has already been fixed ready for the next release. It is normal that dscho will pick up the pacman supported changes automagically, but unless there is a significant breakage the changes don't appear until the next Git release. (see #2162 for an example of something being easily missed)

[dscho]

Or test the current snapshot.

[PhilipOakley]

test the current snapshot.

@fcharlie the snapshots are at https://wingit.blob.core.windows.net/files/index.html

to look at the builds of other branches see https://github.com/git-for-windows/git/branches/active (click the green checkmarks).

@fcharlie, A report back would be appreciated.

[fcharlie]

Good Git-prerelease-2.21.0.windows.1.113.g233535ee04-64-bit.exe fix

[fcharlie]

[PhilipOakley]

Thanks for confirming.