Installer fails due to homedrive / homepath settings

[kienerj]

The installer fails once it tries to set .gitconfig with an error of invalid argument. this error is repeated about 15 times.

Unable to set system config "diff.astextplain.textconv":="astextplain": exit code 128
stderr:
fatal: unable to access 'U://.gitconfig': Invalid argument

It seems the install then still goes thrugh but git remains unusable with the exact same error not being able to find 'U://.gitconfig'

This is due to corporate enforced windows variables with user profile synced to server. Hence HOMEDRIVE/HOMEPATH points to U: instead of windows user profile on C:\Users<username> which is stored in USERPROFILE variable. Hence the installer and git should use USERPROFILE variable to write the settings.

Setup

64-bit Win 10

Git-2.25.1-64-bit.exe

[dscho]

The funny thing is that this command should not need to access your home directory at all... it tries to edit the system config. What happens when you call git config --system a.b c after the (eventually successful) installation?

[kienerj]

The funny thing is that this command should not need to access your home directory at all... it tries to edit the system config. What happens when you call git config --system a.b c after the (eventually successful) installation?

If using an elevated command prompt it works and fails on a normal prompt due to trying to edit gitconfig in C:\Program Files\Git\etc.

And I can get the installation to work without error when following the advice from this answer on stackexchange:

net use u: /delete 
net use u: \\localhost\C$\Users\username

First remove the "invisible" u: partition, then remap it to local userprofile.

This indeed confirms that the issue is with the environment variables the installer want to use. I wonder why this hasn't been raised already? I would assume most developers on windows will suffer from this.

[dscho]

This indeed confirms that the issue is with the environment variables the installer want to use. I wonder why this hasn't been raised already? I would assume most developers on windows will suffer from this.

The problem seems to arise from your environment variables HOMEDRIVE/HOMEPATH not matching USERPROFILE. However, it seems to be the normal case that those are identical. That's why you don't see more bug reports by most developers on Windows.

First remove the "invisible" u: partition, then remap it to local userprofile.

Now, this is interesting. Why do you call it "invisible"?

HOMEDRIVE/HOMEPATH points to U:

This is pretty imprecise. What are the exact values of HOMEDRIVE and of HOMEPATH?

I ask because we have this code to handle construction of HOME from HOMEDRIVE/HOMEPATH:

			DWORD attr, drvlen = GetEnvironmentVariable(L"HOMEDRIVE", NULL, 0);
			e = (LPWSTR)malloc(sizeof(WCHAR) * (drvlen + len));
			drvlen = GetEnvironmentVariable(L"HOMEDRIVE", e, drvlen);
			GetEnvironmentVariable(L"HOMEPATH", e + drvlen, len);
			/* check if the path exists */
			attr = GetFileAttributesW(e);
			if (attr != INVALID_FILE_ATTRIBUTES
					&& (attr & FILE_ATTRIBUTE_DIRECTORY))
				SetEnvironmentVariable(L"HOME", e);
			else
				len = 0; /* use USERPROFILE */
			free(e);

The part I want to point out is /* check if the path exists */. I.e. we only use those values to infer HOME if that path exists.

Now, that means that for some reason, %HOMEDRIVE%%HOMEPATH% is a valid path and refers to a directory yet git.exe still cannot access it. Which is kind of strange, given that the test succeeds.

As to why HOMEDRIVE/HOMEPATH take precedence over USERPROFILE: it is recommended e.g. by https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_automatic_variables?view=powershell-7#home

So the question here really boils down to: what are the exact values of your HOMEPATH and HOMEDRIVE, and do they point to a valid directory, and what does GetFileAttributesW() return for that path and why?

[kienerj]

HOMEDRIVE is "U:" and HOMEPATH is "\" which leads to HOMEDRIVE/HOMEPATH = U:\

I call U: invisible because it doesn't show up in the windows explorer. But when opening a command prompt, it opens in U:. It's a mapped drives which points to the server storing the windows user profiles.

See link in previous comment. This is a common setup corporations use but I don't know much more about it. Important is that it means anything using HOMEDRIVE/HOMEPATH will potentially fail.

[dscho]

I know that it is a common corporate setup to have mapped homedrives. But those most commonly show up in Windows Explorer.

Maybe yours is somehow mounted only when opening it in an interactive command prompt (and Git would work after that, but not before)? Most curious.

[kienerj]

It's never visible even when opening a command prompt. I've read this can happen if it is set by GPO and I know a lot of stuff is set that way.

[dscho]

It's never visible even when opening a command prompt

How does anything even work in that kind of setup?

[dscho]

And, more importantly, why does GetFileAttributesW() think that this is a perfectly fine directory?

[dscho]

And, more importantly, why does GetFileAttributesW() think that this is a perfectly fine directory?

[dscho]

And, more importantly, why does GetFileAttributesW() think that this is a perfectly fine directory?

[kienerj]

I don't know how this works. I searched a bit and apparently you can hide a drive from explorer via registry or group policy.

[dscho]

So how should we detect/handle this? What does other software do in that situation?

[kienerj]

Hm, looking at the error again:

fatal: unable to access 'U://.gitconfig': Invalid argument

What stick out are "//" after U:. I suspect the code takes homedrive and appends a "/" and then takes homepath which in my case is "/" ending up in U:// which is an invalid path. Just a thought.

[dscho]

@kienerj right. But I fail to see how that even comes about, given that HOMEDRIVE and HOMEPATH are set to U: and ``, respectively? Where are those slashes coming from?

[kienerj]

HOMEPATH is actually "\". I edited the previous comment in that regard. Seems the comment processing removes single backslash hence it looked like "". I have to type 2 back slashes to display one in the comments here.