winget-cli: 'winget install' does not (properly, or at all) expand paths on Windows 11, builds 22449 through latest.
Brief description of your issue
winget install
fails to expand paths when encountering user profiles with a name longer than 8 characters. Specifically, a call to std::filesystem::rename
will fail. A trigger may also be a space or dot, or any other special character in the user profile path.
A notable example of the latter are accounts provisioned from Azure AD, as these commonly take the form of NameSurname
, not normalizing special characters, e.g. IvoIvić
, or name.surname
, e.g. fran.kelava
.
Steps to reproduce
This is perfectly reproducible using any package. You do not need to use the exact package from the example.
During your Windows install, sign in with an MSA/AAD account. Your resulting user directory name may include special characters or a dot separating your name and surname, and this must be the case to trigger this issue. OR During your Windows install, skip MSA/AAD login and create a local account longer than 8 characters in length, and add a space in it for good measure.
PS C:\Users\fran.kelava> winget install 'voidtools.EverythingLite'
Expected behavior
The command throws no error.
Actual behavior
PS C:\Users\fran.kelava> winget install 'voidtools.EverythingLite'
Found Everything Lite [voidtools.EverythingLite]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://www.voidtools.com/Everything-1.4.1.1009.x64.Lite.msi
██████████████████████████████ 1.67 MB / 1.67 MB
Successfully verified installer hash
An unexpected error occurred while executing the command:
rename: The system cannot find the file specified.: "C:\Users\FRAN~1.KEL\AppData\Local\Temp\WinGet\voidtools.EverythingLite.1.4.1.1009", "C:\Users\FRAN~1.KEL\AppData\Local\Temp\WinGet\voidtools.EverythingLite.1.4.1.1009.msi"
This may also be related to the problem showcased in #1203, in which an AAD-based account suffered a similar or identical issue. While the author of that issue also had special characters making the issue more difficult, the issue also plainly appears for usernames which do not feature special characters.
In #1203, the issue author saw functionality restored once the dot and special characters were eliminated from the user directory name. [UPDATE] However, based on the replies below, it seems that this is an issue with path expansion in general.
However, I’m afraid I must insist that this issue be properly fixed. It is not acceptable for winget
to ship broken by default in instances where the user cannot influence the name of their user directory, e.g. Azure AD joins in OOBE.
Environment
Windows Package Manager v1.0.11694
Windows: Windows.Desktop v10.0.22449.1000
Package: Microsoft.DesktopAppInstaller v1.15.11694.0
This is a clean install of the latest Dev Channel Insiders build at the time of posting.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 22 (7 by maintainers)
With the latest information provided by all of you, I renamed the issue to better reflect its root cause and magnitude. I can also confirm that the issue persists in build 22463.
Fix confirmed in v1.1.12653.
winget upgrade
andwinget install
now function as expected for.exe
and.msi
installers. See:with versions:
This has been resolved in the latest release of winget (v1.1.12653):
Either spam the update button in the Microsoft Store until you get an update or download it here.
Still not working on 22463:
Feedback hub: https://aka.ms/AAdvvje
It is borked for me on 22454. If your user folder name is less than 8 characters you probably won’t be affected.
This is the first build it was broken for me, weird. Must be a winget thing though.
@jedieaston This issue persists for me through a few Insider builds now. If they’ve been broken, they’ve been broken for a while now, which might be possible but seems unlikely. Considering a normal “ren” will expand the path correctly, I’m inclined to think it’s not the OS.
Works fine for me on latest, it looks like for some reason that the Admini~1 isn’t being expanded by either winget or the system for some reason is my guess