Skip to content
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

[Package Issue]: WinDirStat.WinDirStat - WinGet Forgets Installed Version of WinDirStat.WinDirStat After Upgrade, Causing Repeated Upgrades #173833

Closed
2 tasks done
Lonniebiz opened this issue Sep 16, 2024 · 5 comments
Labels
Help-Wanted This is a good candidate work item from the community. Issue-Bug It either shouldn't be doing this or needs an investigation. Package-Update This package needs to be updated Resolution-Duplicate This issue or pull request already exists
Milestone

Comments

@Lonniebiz
Copy link

Lonniebiz commented Sep 16, 2024

Please confirm these before moving forward

  • I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
  • I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Other

Brief description of your issue

WinGet forgets the installed version of WinDirStat.WinDirStat immediately after upgrading, leading to unnecessary repeated upgrades in subsequent runs.

Steps to reproduce

  1. Open PowerShell
  2. Run winget install windirstat --scope machine to install WinDirStat if not already installed
  3. After installation, run winget upgrade --all --include-unknown
  4. Observe that WinDirStat.WinDirStat shows "Unknown" in the Version column, but has an "Available" version listed
  5. Allow the upgrade to proceed and complete successfully
  6. Immediately run winget upgrade --all --include-unknown again
  7. Notice that WinDirStat.WinDirStat still shows as "Unknown" in the Version column and is again offered for upgrade to the same version that was just installed

Actual behavior

Winget successfully upgrades WinDirStat.WinDirStat to the latest available version. However, it immediately "forgets" this version information. In subsequent runs, even immediately after an upgrade, the Version column remains "Unknown" for WinDirStat.WinDirStat. This results in winget repeatedly offering to upgrade WinDirStat.WinDirStat to the same version in every run, creating a loop of unnecessary upgrades.

Expected behavior

After a successful upgrade, winget should remember and correctly display the installed version of WinDirStat.WinDirStat. Subsequent winget upgrade commands should not offer to upgrade WinDirStat.WinDirStat unless a newer version is actually available. The Version column should show the correct installed version, and WinDirStat.WinDirStat should only be listed for upgrade when there's a genuine new version available.

Environment

Windows Package Manager v1.8.1911
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.4894
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1911.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Screenshots and Logs

No response

@Lonniebiz Lonniebiz added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Sep 16, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage This work item needs to be triaged by a member of the core team. label Sep 16, 2024
@Dragon1573
Copy link
Contributor

image

It don't write DisplayVersion and Publisher to Windows Registry.

@stephengillie stephengillie removed the Needs-Triage This work item needs to be triaged by a member of the core team. label Sep 17, 2024
@stephengillie
Copy link
Collaborator

stephengillie commented Sep 17, 2024

We call this the "upgrade always available" situation.

The package manager operates by matching data in Registry to a compressed copy of the manifests in the repo. Here, the data written by the installer to the Registry doesn't tell which version is installed. So the package manager only knows that you have the package installed, and tries to upgrade and be sure that you have the latest version.

If a ProductCode or UpgradeCode can be added to the manifest, one of these might be the key bit of data to allow the package manager to match with the correct manifest. Then, it should display that no upgrade is available.

@stephengillie stephengillie added Help-Wanted This is a good candidate work item from the community. Package-Update This package needs to be updated labels Sep 17, 2024
@Trenly
Copy link
Contributor

Trenly commented Sep 19, 2024

@stephengillie - That would only work for MSI packages, since EXE files usually have the exact same ProductCode regardless of the version.

@Lonniebiz
Copy link
Author

Which of the duplicates is canonical? None of them seem to be open, and this issue is not resolved.

@Trenly
Copy link
Contributor

Trenly commented Sep 19, 2024

Which of the duplicates is canonical? None of them seem to be open, and this issue is not resolved.

This is not an issue with WinGet - it's an issue with WinDirStat as the linked issues explicitly state

@denelon denelon added this to the 1.10 Packages milestone Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help-Wanted This is a good candidate work item from the community. Issue-Bug It either shouldn't be doing this or needs an investigation. Package-Update This package needs to be updated Resolution-Duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

5 participants