`winget list` does not match `SumatraPDF.SumatraPDF` ID after `list` provides it

[garretwilson]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget list

Brief description of your issue

winget list --id SumatraPDF.SumatraPDF isn't matching an installed SumatraPDF that winget list SumatraPDF itself shows.

This especially prevents upgrading, e.g. winget upgrade -id SumatraPDF.SumatraPDF does not match the existing SumatraPDF installation. Nevertheless the main issue is that winget list --id is not matching an ID that winget list itself returns; that is an inconsistency that is cause for concern, and the root cause should be understood. This goes to the core of security: being able to trust that winget --id … --source … --exact will match the intended target.

This issue was originally submitted as microsoft/winget-pkgs#418621, but was told it should be resubmitted here.

Steps to reproduce

1. Manually Install SumatraPDF-3.6-64-install.exe.
2. Run winget upgrade; it will show that SumatraPDF needs upgrading.
3. Run winget list SumatraPDF. It displays:

   Name       Id                    Version Available
   --------------------------------------------------
   SumatraPDF SumatraPDF.SumatraPDF 3.6     3.6.1
   

4. Run winget list --id SumatraPDF.SumatraPDF.

Expected behavior

winget list --id SumatraPDF.SumatraPDF should list the package that winget list SumatraPDF itself showed earlier!

Oddly winget download --id SumatraPDF.SumatraPDF does work! But winget upgrade --id SumatraPDF.SumatraPDF does not match.

Actual behavior

No installed package found matching input criteria.

Environment

Windows Package Manager v1.29.280

Windows: Windows.Desktop v10.0.26200.9168
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.29.280.0

[github-actions]

Possible duplicate(s):

Thank you for submitting this issue.

The issue(s) below may already track your request or bug. Please take a look — if one of them matches, give that issue a 👍 and close this one as a duplicate. Older or curated issues are preferred as the canonical one to follow.

• List or Uninstall by id does not return expected result #2528 — "List or Uninstall by id does not return expected result" — directly describes --id failing to find packages that appear in a plain winget list
• --exact results in not finding package even when exact is installed #4632 — "--exact results in not finding package even when exact is installed" — --id (which uses exact matching) not finding packages that winget knows are installed
• Uninstallation: No installed package found matching input criteria. (--name/--id behaviour) #3093 — "Uninstallation: No installed package found matching input criteria. (--name/--id behaviour)" — covers the same inconsistency where --id fails to match a known installed package
• "No installed package found matching input criteria." when attempting to update #2686 — ""No installed package found matching input criteria." when attempting to update" — same symptom when using --id to upgrade an installed package
• Certain winget packages that are found by Get-WinGetPackage are not returned by Get-WinGetPackage -Id #6161 — "Certain winget packages found by Get-WinGetPackage are not returned by Get-WinGetPackage -Id" — same root issue (filtering by ID misses packages the unfiltered list returns)

Template: msftbot/duplicate/surfaced by Duplicate Surfacing

[garretwilson]

It does seem to be a duplicate of #2528. Wow, open since 2022. I'm surprised that Microsoft cares so little about security for one of its primary installation tools.