Chocolatey-coreteampackages: (git.install) Access to the path denied

[Skolzack]

Trying to install the package git.install on Windows 10.

Using Git LFS
Installing 64-bit git.install...
git.install has been installed.
VERBOSE: Trying local and machine (x32 & x64) Uninstall keys
VERBOSE: Retrieving all uninstall registry keys
VERBOSE: Trying Uninstall key property 'InstallLocation'
git.install installed to 'C:\Program Files\Git'
ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to
Stop: Access is denied
git.install can be automatically uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
see the changes (or in powershell/cmd.exe just type refreshenv).
git.install not installed. An error occurred during installation:
Access to the path 'C:\ProgramData\chocolatey\lib\git.install\tools\Git-2.13.3-64-bit.exe' is denied.
The process cannot access the file 'C:\ProgramData\chocolatey\lib\git.instal.chocolateyPending' because it is being used by another process.

[pauby]

So you're trying to uninstall it?

I get this exact same error when I tried to do it too. The issue for me was Malwarebytes was scanning the folder and for some reason holding onto git.exe (not idea why). My solution was to exclude the bin folder where git.exe sits. As soon as I did that it was fine.

You might nto have malwarebytes but try something like Lockhunter on git.exe and see if there is something locking it. Also make sure you have closed everything that may well be using it at that time.

[Skolzack]

No, I'm trying to install it and I don't have malwarebytes. I'll try again in another clean machine.

[pauby]

Malwarebytes was just an example. Any AV may well be scanning it. The pertinent bit of your logs is:

Access to the path 'C:\ProgramData\chocolatey\lib\git.install\tools\Git-2.13.3-64-bit.exe' is denied.
The process cannot access the file 'C:\ProgramData\chocolatey\lib\git.instal.chocolateyPending' because it is being used by another process.

So this isn't a package issue.

[ghost]

I get this error as well. In an elevated PS session full log as a gist here:

PS C:\Windows\system32> choco install git.install -y --verbose
**…**
Using Git LFS
Installing 64-bit git.install...
git.install has been installed.
VERBOSE: Trying local and machine (x32 & x64) Uninstall keys
VERBOSE: Retrieving all uninstall registry keys
VERBOSE: Trying Uninstall key property 'InstallLocation'
git.install installed to 'C:\Program Files\Git'
ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to
Stop: Access is denied
git.install can be automatically uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
see the changes (or in powershell/cmd.exe just type `refreshenv`).
git.install not installed. An error occurred during installation:
Access to the path 'C:\ProgramData\chocolatey\lib\git.install\tools\Git-2.13.3-64-bit.exe' is denied.
The process cannot access the file 'C:\ProgramData\chocolatey\lib\git.instal\.chocolateyPending' because it is being used by another process.

However, after starting a new PS session, git appears to be installed and working:

PS C:\Users\kwall> git --version
git version 2.13.3.windows.1
PS C:\Users\kwall>

[AdmiringWorm]

this is a known issue (well known by me at least), it seems like sometimes the package continues the execution even before the installer have been released (kinda similiar to when an installer haven't completely run yet).

I've not yet found a solution to this though, but the error should still not happen as we ignore errors when trying to remove the installer (somehow this seem to not work correctly though).

[ghost]

@AdmiringWorm I'll provide whatever debugging you need. It reproduces easily here.

[AdmiringWorm]

@kurtwall thanks for that, but unfortunately I'm not exactly sure what I need for debugging purposes here.
I plan to try out a few things, unfortunately I have my hands full right now, but hope to get around to it sometime this weekend.

[Skolzack]

@AdmiringWorm Thank you for spending your time to look into this issue, we appreciate it.

[AdmiringWorm]

@Skolzack no problem.
Just a note, I believe I'll have an update tomorrow that I want you and @kurtwall to test out before we push out an official version (minor change which I believe will work, but want to test out first).

[SimY4]

Hey, guys.

Just curiuos if is there any progress on this issue?

[AdmiringWorm]

@SimY4 no unfortunately not, life got in the way and I completely forgot about this issue.
Unfortunately I've also forgotten what changes I had planned 😢, so no progress at all

[lawrence-c]

I don't suppose you have anymore updates for this? :)

[AdmiringWorm]

@SurferL Sorry, I'm afraid there isn't any update on this one.

[lawrence-c]

@AdmiringWorm I don't suppose you have a work around for this for now?

[AdmiringWorm]

@SurferL not really.
However, I think it may be a problem with git that it exits before the installation is done, possibly only when an upgrade is in process.

What you could try, is to first uninstall git, before you try to upgrade it.
This is just speculations though, I've almost never (maybe just once) ran into this issue myself on my own computer.

[lawrence-c]

@AdmiringWorm Well, I'm just doing a straight installation from scratch so don't think it could be that? (via Ansible)

[AdmiringWorm]

I see, then that idea with the updating being the problem is wrong, but it is still the installer that haven't completely finished when control is returned to the script.

I think we'll end up with just ignoring such failures in the install script in the end, either that or try to detect if the process is still running, or maybe both.

[majkinetor]

I am sure this is not related to package as @pauby already noted. IMO a choco defect. This issue is going to be closed soon.

[Saniok88]

One of reasons, why this error may happen is the too long filename (more, than 256 symbols, starting from Disk root and ending whole folder depth and a filename - if all of this is longer, than 256 symbols, those files are locked, and can not be deleted, until you manually shorten all folder names)

[david-kishi]

I know this topic was closed but in the case anybody is looking this up again, I had the same issue, but miraculously, I simply closed CMD and reopened it 'Running as Admin' and the installation worked.