Hey, error with pull and push in Android Studio

[LarMont]

• 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.23.0.windows.1
cpu: x86_64
built from commit: 4db2e5cc9e1522131a039cbad3970f147a39f0ce
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 [Version 10.0.17763.678]
**

• 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: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled 
**

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

** This problem occurs in android studio, but in the TortoiseGit it is not **

Details

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

** I usually use Git in Android Studio **

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

** This problem with pull and push, maybe and other **

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

** Update my project **

• What actually happened instead?

** this error

warning: failed to restrict file handles (87)  
handle #0: 0000000000000228 (type 3, handle info (1) 0 
handle #1: 000000000000026c (type 3, handle info (1) 1 
handle #2: 0000000000000678 (type 3, handle info (1) 1  
This is a bug; please report it at https://github.com/git-for-windows/git/issues/new  
To suppress this warning, please set the environment variable  SUPPRESS_HANDLE_INHERITANCE_WARNING=1  
remote: HTTP Basic: Access denied Authentication failed for 'my url'
**

 - If the problem was occurring with a specific repository, can you provide the
   URL to that repository to help us with testing?

** I can not provide url to that repository, sorry **

[PhilipOakley]

Hmm that's not good. appears same as #2301

That error was thought fixed previously - try search the closed issues for "warning: failed to restrict file handles" to see if you can see the cause and possible places that may have re-surfaced that issue.

[LarMont]

Sorry, but it didn’t help much.

[dscho]

I fixed the formatting of your bug report. Please be more careful in the future, you want the people who you ask for help to be careful, too.

The biggest thing I see here is that stdin is marked as non-inheritable: https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-gethandleinformation says that 0x1 is HANDLE_FLAG_INHERIT, but the line in question reads:

handle #0: 0000000000000228 (type 3, handle info (1) 0

Where the last number is the result of the GetHandleInformation() call: https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/compat/mingw.c#L1883-L1887

So what I would suggest is to patch in a hack after this line: https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/compat/mingw.c#L1754

If you install Git for Windows' SDK, call sdk cd git, and then add something like this after that line:

{
  DWORD fl = 0;
  if (!GetHandleInformation(si.StartupInfo.hStdInput, &fl) || !(fl & HANDLE_FLAG_INHERIT))
    si.StartupInfo.hStdInput = INVALID_HANDLE_VALUE;
}

you should be able to build a test installer via sdk build git-and-installer and test this theory. If this gets you anywhere, I'll help you clean up the patch and open a PR.

[LarMont]

I fixed the formatting of your bug report. Please be more careful in the future, you want the people who you ask for help to be careful, too.

The biggest thing I see here is that stdin is marked as non-inheritable: https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-gethandleinformation says that 0x1 is HANDLE_FLAG_INHERIT, but the line in question reads:

handle #0: 0000000000000228 (type 3, handle info (1) 0

Where the last number is the result of the GetHandleInformation() call: https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/compat/mingw.c#L1883-L1887

So what I would suggest is to patch in a hack after this line: https://github.com/git-for-windows/git/blob/v2.23.0.windows.1/compat/mingw.c#L1754

If you install Git for Windows' SDK, call sdk cd git, and then add something like this after that line:

{
  DWORD fl = 0;
  if (!GetHandleInformation(si.StartupInfo.hStdInput, &fl) || !(fl & HANDLE_FLAG_INHERIT))
    si.StartupInfo.hStdInput = INVALID_HANDLE_VALUE;
}

you should be able to build a test installer via sdk build git-and-installer and test this theory. If this gets you anywhere, I'll help you clean up the patch and open a PR.

I followed your advice, started installing git sdk, and in the process of git asked for my login / password, and this helped solve my problem, I think the problem was not in git sdk, but the need to re-enter my git, thank you very much

[PhilipOakley]

This seems to leave a number of loose ends, such as why/how you @LarMont got into the state that then created the file handles error.

It maybe that this is simply (on your machine) an old version of Git for Windows embedded/linked in Android studio (or it even picked up something you already had), and that when you then loaded the sdk it meant you obtained a fresh (recent) copy of Git which no longer has the error.

I don't think that simply using a username and password to access another site (during the sdk download and install process) would itself fix the problem and the inheritance issue that dscho identified.

I.e. is the fix dscho identified still needed? #loose-end

[dscho]

is the fix dscho identified still needed?

I did not identify a fix, but a lead to investigate. And yes, that investigation is still needed. But it seems that nobody can be bothered to contribute a little bit of their time back to Git for Windows, so I guess it will remain uninvestigated.