-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot upgrade/uninstall nested portables coming from an older version of WinGet #3279
Labels
Command-Uninstall
Issue related to WinGet Uninstall
Command-Upgrade
Issue related to WinGet Upgrade
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Portable
Issue related to portable package
Comments
microsoft-github-policy-service
bot
added
the
Needs-Triage
Issue need to be triaged
label
May 27, 2023
2 tasks
denelon
added
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Portable
Issue related to portable package
and removed
Needs-Triage
Issue need to be triaged
labels
May 30, 2023
2 tasks
2 tasks
same issue. |
[Policy] Command-Upgrade |
microsoft-github-policy-service
bot
added
Command-Uninstall
Issue related to WinGet Uninstall
Command-Upgrade
Issue related to WinGet Upgrade
labels
Jan 11, 2024
This was referenced Mar 7, 2024
2 tasks
2 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Command-Uninstall
Issue related to WinGet Uninstall
Command-Upgrade
Issue related to WinGet Upgrade
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Portable
Issue related to portable package
Brief description of your issue
Nested portable applications where the executable is located inside of a subdirectory in the archive suffered from issue #2909 that was patched in the preview version of WinGet in PR #3002. Users can benefit from the patched behavior if they upgrade to the preview version and install these apps for the first time (no prior installation). However, users coming from WinGet 1.4 who already had the package installed need to first uninstall the existing installation or upgrade to a newer version if available to get the correct value in their PATH env variable. The issue is that users are not able to perform an uninstall/upgrade of these apps and the command gets stuck indefinitely.
Steps to reproduce
Gyan.FFmpeg
,BurntSushi.ripgrep.GNU
,Helm.Helm
from a USER shell (again to prevent symlink creation). Install an older version to test upgrade scenario (e.g.winget install Gyan.ffmpeg --version 5.1.2
). If you try to uninstall the apps at this stage, the command would succeedExpected behavior
Uninstall/Upgrade succeeds
Actual behavior
Command gets stuck indefinitely at
Starting package uninstall...
/Starting package install...
(in upgrade scenario)Interesting thing to note here is that in the upgrade scenario, the values are actually overwritten in the registry, but the archive isn't extracted properly inside the Packages directory. Here I was upgrading Gyan.FFmpeg from
5.1.2
to6.0
Workaround
The workaround I found to remove these packages to unblock upgrade/uninstall scenario is:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\
Logs
Logs generated after having to manually Ctrl-C the indefinitely stuck commands
WinGet-2023-05-27-17-03-08.610.log (stuck in upgrade command)
WinGet-2023-05-27-17-09-28.883.log (stuck in uninstall command)
Environment
The text was updated successfully, but these errors were encountered: