Uninstalling Admin-Installed Git 2.10.1 does not clean up %PROGRAMFILES%/Git correctly

[sxlijin]

• 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.10.1.windows.1
  sizeof-long: 4
  machine: x86_64
  

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

  $ cmd /c ver
  Microsoft Windows [Version 6.1.7601]
  Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
  

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

  I don't believe the installation options affect this in any way. I tried multiple installation options with the 2.10.1 prerelease installer and they all produced this bug.

  $ cat /etc/install-options.txt
  Path Option: BashOnly
  SSH Option: OpenSSH
  CRLF Option: LFOnly
  Bash Terminal Option: MinTTY
  Performance Tweaks FSCache: Enabled
  

Details

• 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.

  1. Install via "Run as Administrator" (using UAC - the account I work on is not an Administrator).
  2. Uninstall via "Programs and Features"

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

  %PROGRAMFILES%/Git is gone.

• What actually happened instead?

  %PROGRAMFILES%/Git is left behind.

• Why does this matter?

  Because the %PROGRAMFILES%/Git folder gets left behind, the local user installer (if invoked following the aforementioned uninstallation) defaults to %PROGRAMFILES%/Git for an install location. While the user can manually point it to the appropriate path in AppData, it's not a very clear install path.

  I don't have this issue with version 2.10.0.windows.1.

[sxlijin]

First mentioned in a comment on #870 re the prerelease installer.

[nalla]

My first guess is that this is due to the fact that you used the replace missing icon workaround by copying the icon manually in the #870 issue. The uninstaller only removes files that it installed. So with that manual work around you added an unknown file to the install dir.

I guess the next uninstall will run through properly again.

[sxlijin]

@nalla I never used the missing icon workaround, I only ever used the prerelease installer. This issue has also persisted across multiple uninstall-install cycles.

[fourpastmidnight]

It would be helpful to know which folders and/or files are left behind. Throughout development of the MSI, the MSI installer is also leaving folders/files behind. I'm wondering if it's the same set of folders/files. It's on my short list of things to look into for the MSI.

[sxlijin]

@fourpastmidnight

$ tree Git
Git
└── mingw64

1 directory, 0 files

[dscho]

@sxlijin could you install the Git for Windows SDK, then verify that you can make an installer, then add

Type: dirifempty; Name: {app}\{#MINGW_BITNESS}

in /usr/src/build-extra/installer/install.iss just before the [Code] section, make another installer and verify that the patched installer uninstalls fine?

That would help me very, very much.

[sxlijin]

Before I forget about this, the reproduction steps I listed are slightly flawed. It seems that to consistently reproduce, I have to run G4W 2.10.0 and then G4W 2.10.1 (no uninstall in between).

SHA-512s are as follows:

$ sha512sum Git-2.10.0-64-bit.exe Git-2.10.1-64-bit.exe
78692dbb7e281515e4d46411838ed1caa0a3bbc48b210dd9950118ff27ca876aecb51b2554211b5c66a1fa687e1849693be8360187b59a7795f33d9d6a63ac51  Git-2.10.0-64-bit.exe
1bd98ba6dc3e715d61cea7772f521eb292f66b1735904f821786e7672febacf4f12a9dd7215aef0f01e99710daa78e9010df7de2cc918ed96080117ca8d14425  Git-2.10.1-64-bit.exe

[sxlijin]

@dscho when I made my previous comment I was able to make an installer (off 21a47dfa378f82f2e2188bde31296fa976713f99) but now it keeps hanging on "Launching Inno Setup compiler..." - any ideas?

[dscho]

it keeps hanging on "Launching Inno Setup compiler...

It is not really hanging. It is working really, really hard. You can see that when looking at the /usr/src/build-extra/installer/install.log file. It is compressing the files using the LZMA method, which is taking quite a few CPU cycles to happen.

[sxlijin]

@dscho thanks for that! Re your fix, it only sort of works for me. After uninstalling, I now have:

$ tree Git
Git

0 directories, 0 files

I've been testing by manually blowing away %PROGRAMFILES%/Git, installing 2.10.1 using "Run as administrator", installing the patched installer using "Run as administrator", and uninstalling via Programs and Features.

[dscho]

@sxlijin I am terribly sorry to leave you hanging for so long! For the record, please feel free to ping me when you see that a ticket fell off my radar, waiting for my response.

So it kinda works? What if you add

Type: dirifempty; Name: {app}

too?

This would be a nice fix in the upcoming Git for Windows v2.11.0, if it works.

[sxlijin]

@dscho no worries.

The fix works for me!

I've made a branch with the fix at my fork, but I can't seem to PR it in (GH is complaining about entirely different commit histories?). SubmittingPatches also describes a very long email workflow that doesn't seem to be necessary per se for this, and perhaps it'll be better for you to just make the fixes since you know the process better than me. I'm happy to try to figure stuff out if you'd like, though.

[dscho]

I can't seem to PR it in (GH is complaining about entirely different commit histories?).

Heh... You pushed this branch into your fork of git-for-windows/git, but it should have been a fork of git-for-windows/build-extra...

SubmittingPatches also describes a very long email workflow that doesn't seem to be necessary per se for this

The SubmittingPatches document applies to upstream Git. And yes, it is a challenging process, I agree. Luckily, your changes do not need that process, as you only touched files that are part of Git for Windows' build process. So upstream Git never will have a chance to approve (or reject) these changes.

I ended up cherry-picking the commit, touching up the commit message while at it.

Thank you for helping make Git for Windows better!