Issue: Chocolatey - Unable to install/uninstall if gsudo is running

[majkinetor]

Allow updating gsudo when it is running. Currently I get ERROR: Unable to install/uninstall if gsudo is running

I propose to save new version on temp location then replace it on next gsudo startup.

[gerardog]

For an upgrade process I could try to rename gsudo.exe to gsudo.exe.previous. But that file would stay there for a while. I might delete it when starting or exiting gsudo, but I wouldn't be 100% proud of that solution. I prefer the main app does not perform installation steps. I rather leave the .previous file hanging there until the next choco upgrade/uninstall.

You would still see that error if both gsudo.exe and gsudo.exe.previous are in use.

[gerardog]

I drafted it on PR #75. Let me know your thoughts. I will start testing when I got some time. The choco pkg is quite sensitive. A bad fix can cause many issues.

[majkinetor]

The choco pkg is quite sensitive. A bad fix can cause many issues.

What do you mean ?

[gerardog]

What do you mean ?

I've received multiple tickets regarding the installation process in the past. (users have multiple scenarios and environment types) Any change should go through 'extensive' testing before a release. Just let's be careful.

[gerardog]

Hi folks,
I really had a couple of rough months lately and wasn't able to focus on this. I finally got some time. plus gsudo got a few requests that deserve a new release. So it is time to review this now.

I tried my quick and dirty commit #75 and it totally failed. All my assumptions on how Chocolatey works were wrong.
I am not really an expert on Chocolatey. I naively decided gsudo should add the uncompressed package bin folder to the path. Disabled choco shims because they introduced a bunch of additional problems.

This means gsudo.exe is used ran and locked from c:\ProgramData\chocolatey\lib\gsudo\bin.

When you upgrade gsudo, it tries to move everything from c:\ProgramData\chocolatey\lib to c:\ProgramData\chocolatey\lib-bkp. That is done on a file by file basis, which fails if gsudo.exe is open.

This happens before the custom steps defined in chocolateyInstall.ps1 and chocolateybeforemodify.ps1 are ran. Modifying those files is useless AFAIK.

Right now I don't know if this feature is achievable. 😢

ps: Maybe, if we make the gsudo choco pkg install it in another folder, like c:\ProgramData\gsudo... then all file operations would be handled by the .ps1 scripts, and we can code it as we want. Nonetheless I doubt we can get this done by v0.8.

[TheCakeIsNaOH]

ps: Maybe, if we make the gsudo choco pkg install it in another folder, like c:\ProgramData\gsudo... then all file operations would be handled by the .ps1 scripts, and we can code it as we want. Nonetheless I doubt we can get this done by v0.8.

In this case, I would suggest using Get-ToolsLocation, which defaults to C:\tools. It is the preferred location for portable programs in choco.

[gerardog]

I've made some changes to implement this.

The next release will no longer add C:\ProgramData\chocolatey\lib\gsudo\bin\ to the path. In fact, it will remove that dir from $env:PATH.
It will use Get-ToolsLocation as @TheCakeIsNaOH suggested, for example C:\tools\gsudo\v1.0.3.0\. Then create a folder symlink C:\tools\gsudo\Current\ => C:\tools\gsudo\v1.0.3.0\, and add Current to the path (what Scoop does off-the-shelve).

Now, according to my (many) tests, even if Current\gsudo.exe is open, I can delete the Current symlink and recreate it to the new version, effectively upgrading to the new version.

For uninstalling, I just delete C:\tools\gsudo recursively. Anything not deleted is renamed as *.deleteMe and marked for deletion upon restart.

Now, people will need to upgrade to this new (to be released) version without using gsudo, and only after that they could gsudo choco upgrade gsudo for future versions. This happens because every choco pkg <= 1.0.2 (current latest release) installs to choco's bin folder (sorry!) (like C:\ProgramData\chocolatey\lib\gsudo) and further choco upgrade blows immediately when it's trying to decompress the new package. (no scripts from the new version are even remotely executed). You get something like:

 (5) Access is denied: [\\?\C:\ProgramData\chocolatey\lib-bkp\gsudo]
Error during backup (move phase):
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib-bkp\gsudo\bin\gsudo.exe]

But, for those who sucessfully upgrade to the upcoming release (v1.1.0) i.e. with gsudo closed, they will be able to gsudo choco upgrade gsudo to go to, for example, v1.1.1, v2, etc.

Anyone want review the code? 64d4bbc...Feature.PwshSyntax

[gerardog]

Maybe help testing it?

choco install gsudo -pre --version=1.1.0-Feature-PwshSyntax47

EDIT: TBH, not sure how much can be tested with only one >v1.0.2 package. A forced upgrade will fail because it wont be able to overwrite C:\tools\gsudo\v1.1.0.0\gsudo.exe and that is actually ok. It's the target folder, shouldnt exists if we are upgrading.

[gerardog]

Fix released in v1.1.0.
As explained above, you will need to upgrade to v1.1.0 first, and then you could gsudo choco upgrade gsudo for the following versions.