Symlinks are not created for portable installations

[clesmian]

Brief description of your issue

When installing a portable app, the executable is correctly extracted and stored into the correct location, but the symlink referenced in the respective sqlite DB is not created.

IMPORTANT: the chosen example is restic, but it is not limited to this tool. A different example would be VirusTotal.YARA

Steps to reproduce

Using the example of restic:

1. Run winget install restic

Expected behavior

• restic is installed to the specified portablePackageUserRoot
• a symlink C:\Users\<USER>\AppData\Local\Microsoft\WinGet\Links\restic.exe is created pointing to the installed file is created
• the directory C:\Users\<USER>\AppData\Local\Microsoft\WinGet\Links\ is added to the users PATH

It is possible to start the tool using restic

Actual behavior

• restic is installed to the specified portablePackageUserRoot
• the directory <portablePackageUserRoot>\restic.restic_Microsoft.Winget.Source_8wekyb3d8bbwe is added to the users PATH

This makes the tool not available under the alias restic, but only restic_0.15.2_windows_amd64 which is the executable stored to disk

Environment

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

Windows: Windows.Desktop v10.0.19045.3271
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.1881.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %USERPROFILE%\tools\
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages

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

[mdanish-kh]

Symlinks are only created when the command is run from an admin shell or when developer mode is enabled in Windows.

This makes the tool not available under the alias restic, but only restic_0.15.2_windows_amd64 which is the executable stored to disk

This is a known bug that's being tracked in #3437

The workaround to your issue is to uninstall the current installation and install from an admin shell / turn developer mode on in Windows that'll create a symlink with the correct alias.

[clesmian]

Sorry, I closed this one to early.

My expectation would be that the link directory is added to path and a link to the extracted file is created rather than the extracted file to be renamed. Or do I misunderstand something?

[mdanish-kh]

My expectation would be that the link directory is added to path and a link to the extracted file is created rather than the extracted file to be renamed. Or do I misunderstand something?

That's exactly what happens in symlinked installations (i.e., admin shell / developer mode). The extracted file isn't renamed but the symlink created in the Links directory is renamed to match whatever is written in the PortableCommandAlias / Commands field in the package manifest. If the field isn't specified in the manifest, then the symlink created will have the same name as the extracted executable.

[clesmian]

Ok, I understand, but then my question is, why the actual install location is added to the path. Wouldn't it be better to reduce the additions to path to the necessary minimum?

[mdanish-kh]

Ok, I understand, but then my question is, why the actual install location is added to the path. Wouldn't it be better to reduce the additions to path to the necessary minimum?

Creating symlink requires admin privileges and if the installation is from a user shell (unelevated, non-admin), then WinGet has no other choice but to resort to installing a package in the Packages directory and putting the entire location in the PATH variable for the command to be accessible in the shell. There may be other solutions to this but WinGet's current implementation of installing portables is roughly:

• Non-admin / User shell and Developer mode Off -> Non-symlinked installations with entire location put in PATH variable
• Admin shell/Developer mode ON -> Symlink created in Links directory that is already available in PATH

[clesmian]

Excuse my ignorance, I'm just more used to linux with links being no big deal. Thank you for explaining it to me and thanks for your very fast response!

Just a suggestion. In the absence of an actual fix, it would be quite helpful, if the output was a bit more verbose. E.g. by saying that it failed to create the symlink rather than suggesting that everything went fine and that you can use the command

[mdanish-kh]

Just a suggestion. In the absence of an actual fix, it would be quite helpful, if the output was a bit more verbose. E.g. by saying that it failed to create the symlink rather than suggesting that everything went fine and that you can use the command

Looking at #2368 where this feature of supporting installing portables in user shells was added (previously one could only install in admin shell), I don't see any discussions around the point you mentioned. I am not sure if you can classify this as "absence of an actual fix" or the "intended behavior" when you installing from user shells (non-developer mode). Might be a good idea to raise a new issue for this request.

Coming back to the original issue you had, I guess we can safely mark this as duplicate of #3437 if you don't have any reservations?