.gnupg directory created at root of C drive

[PRabahy]

I just ran

git log --show-signature

and got

gpg: directory /c/.gnupg' created gpg: new configuration file/c/.gnupg/gpg.conf' created
gpg: WARNING: options in /c/.gnupg/gpg.conf' are not yet active during this run gpg: keyring/c/.gnupg/pubring.gpg' created

I'm not sure if this is a bug or misconfiguration, but I didn't expect it to create a new gpg.conf file. I already have a symlink at C:\Users\USERNAME.gnupg pointing to C:\Users\USERNAME\AppData\Roaming\gnupg. My expectation was that git-for-windows would have used either of those paths.

[dscho]

Please do respect our bug reporting guidelines linked from our home page. Pretty much all information about your setup is missig.

[dscho]

In addition:

I already have a symlink at C:\Users\USERNAME.gnupg pointing to C:\Users\USERNAME\AppData\Roaming\gnupg.

I suspect that you meant to include a backslash between USERNAME and .gnupg.

Also, what kind of symlink are you talking about? An MSys2 one? What command did you use to create it?

Please clarify, and please do not make me ask for every detail of your setup specifically but volunteer this information liberally. This interaction would be very tedious otherwise.

[PRabahy]

Sorry about the missing info.

1. I searched for issues containing gnupg, but only found one that didn't appear to be relevent.
2. git version 2.5.3.windows.1
   2a. I am running Windows 7 64bit.
3. I believe my description was thorough enough, please let me any other specifics that you need.
4. To expand on my example, I did the following: Start Sourcetree. Open my bitcoin repo (git@github.com:bitcoin/bitcoin.git). Click the Terminal button. In the terminal, type "git log --show-signature" and press enter. The results were as posted.
5. I don't believe that this is related to the repo, but I was working on git@github.com:bitcoin/bitcoin.git.
6. I am prepared to test fixes.
7. Sorry about not including all the info in the first place. I just noticed the issue and was trying to get it recorded before I went to bed.
8. Hopefully this can now be considered an outstanding bug report.

Good catch about the missing backslash. My bad.
I created the symlink a while ago, but I believe it is a Windows NTFS symlink. If I remember correctly I used "mklink /D" to create the symlink. I believe I created it because different gnupg programs made their own folders and this allowed me to consolidate it.

Hopefully this also helps (truncated output to just the relevant stuff):
C:\Users\PRabahy>dir
05/03/2014 07:05 PM .gnupg [C:\Users\PRabahy\AppData\Roaming\gnupg]

Also likely relevant is that I Gpg4win 2.2.5 installed. From that I have GNU Privacy Assistant (GPA) 0.9.7 [8ce9480] and Kleopatra 2.2.0-gita3c9200 (2015-06-09) installed.

[dscho]

Start Sourcetree

I guess that one is the culprit. I do not know how SourceTree opens the Git Bash, but we had reports before that it does not do it right.

If I remember correctly I used "mklink /D" to create the symlink.

If I remember correctly, MSys2 programs do not handle symbolic links created with mklink.

[PRabahy]

Using that info, I ran a couple of small tests.

1. I deleted the .gnupg folder that git for windows created. (so that I had a clean slate)
2. I started Git Bash from the start menu instead of SourceTree.
3. I ran the "git log --show-signature" command.
   Cool, it ran successfully! Looks like SourceTree might be the issue.

Next I wanted to verify if my symlink was causing any trouble.

1. I renamed my symlink from .gnupg to .gnupg2.
2. I re-ran the command again.
   This caused git for windows to create a new .gnupg folder in the correct location.
   gpg: directory /c/Users/PRabahy/.gnupg' created gpg: new configuration file/c/Users/PRabahy/.gnupg/gpg.conf' created
   gpg: WARNING: options in /c/Users/PRabahy/.gnupg/gpg.conf' are not yet active during this run gpg: keyring/c/Users/PRabahy/.gnupg/pubring.gpg' created

These tests lead me to believe that the problem is with SourceTree, not the symlink. It appears that git for windows follows the symlink as long as SourceTree didn't launch it.

From there I did a little investigation into how SourceTree launches the git terminal. According to Processes Explorer, when SourceTree launches git terminal, it calls

"C:\Windows\System32\cmd.exe" /c "C:\Program Files\Git\usr\bin\sh.exe" --login -i

When I start it from the start menu, it calls

"C:\Program Files\Git\usr\bin\bash.exe"

SourceTree automatically sets the current directory to the folder associated with the git repo. From the start menu, I need to cd to the proper directory, but after that Process Explorer shows both of their current directories as

C:\Users\PRabahy\Documents\bitcoin\

[dscho]

What do HOME, HOMEDRIVE, HOMEPATH, and USERPROFILE look like?

[PRabahy]

From git bash launched from the start menu:
$ echo $HOME
/c/Users/PRabahy
$ echo $HOMEDRIVE
C:
$ echo $HOMEPATH
\Users\PRabahy
$ echo $USERPROFILE
C:\Users\PRabahy

From shell launched from SourceTree:
$ echo $HOME
/c
$ echo $HOMEDRIVE
C:
$ echo $HOMEPATH
\Users\PRabahy
$ echo $USERPROFILE
C:\Users\PRabahy

Looks like $HOME might be the problem.

[dscho]

From shell launched from SourceTree:
$ echo $HOME
/c

That is most likely the problem...

[dscho]

Unfortunately, simple exporting HOME in the Git Bash does not fix it for me in my rudimentary test. Maybe you can come up with a clever way to fix it?

[PRabahy]

I added a comment to https://jira.atlassian.com/browse/SRCTREEWIN-3704 because i believe that would let me work around the issue. I'll try some more experiments tonight.

[PRabahy]

I found a hacky workaround. I set a HOME user environment variable to C:\Users\PRabahy and it appears to be working now.

I don't know if this makes any difference, but I run as a standard user with UAC enabled. I have an admin user that I use UAC elevation to run installers as. If HOME is supposed to get set as part of the install, that wouldn't work in my configuration because the the user directory getting set would be the administrators instead of my standard users.

[dscho]

If HOME is supposed to get set as part of the install

No, it should actually be set by MSys2 itself, based on the HOMEDRIVE and HOMEPATH variables, possibly falling back to the USERPROFILE variable. However, to allow overriding invalid values in those variables, the MSys2 runtime will heed HOME over the others -- if set.

Now, the question is where this is set incorrectly...

[dscho]

@PRabahy remember how I asked you to follow the guidelines to explain your setup? I guess that was really crucial, after all. The SourceTree thing was really important to know. I now narrowed it down in two days of tedious debugging and have a fix.

Please, next time, make it easier for me by really trying to get me as quickly to reproduce the problem you are experiencing (i.e. without having to ask for many additional details; just give them all to me, you will have to describe all the details anyway).

[PRabahy]

Originally I didn't realize that SourceTree was involved at all. Thanks for all your hard work debugging this! It sounds like you got the issue nailed down, but if you need someone to test it just send a beta my way.

[PRabahy]

Verified fixed in 2.6.0.

[dscho]

Thanks for verifying and reporting back.