[BUG] Plenty of tolerated custom paths for updates

[DoctorMG]

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

2026.2.5

Windows version, edition, and architecture

Windows 11 Pro x64

Describe your issue

Since some weeks more and more programms seem to tolerate my path policy. I don't want all the new huge software packages (those electon etc. tools that eat GBytes for housing an editor or other one-click purposes) on my fast but small SSD drive. It is mainly for the OS and some programms that really have advantage from the drive speed.
I have tons of hard disk space on other drives D:, E; And I am sure, I am not the only Windows user with exactly this constellation. Otherwise I liked to know, where they get the SSD space for free.
Although I can write a path in UniGetUI it is tolerated - and instead of having the Blender Update in "D:\dev\blender foundation" - surprise, surprice - it is in "C:\Program Files\blender foundation". Even worse: now it eats space in C and in D, since the old version is still there. Same with Zotero, same with Trilium, same with R for Windows and many more. For some I started to more with Windows Links - but honestly - what use has the GUI work, if I need to do such admin works now on another prompt?

This is frustating. First it looked, that UniGetUI could help with updates - but now with the need to checkup every install it comsumes more time than manually download and update tools.
Maybe some of you have an idea how I can really stop this mess, since I see that the idea would be excellent. Tolerating hard entered admin paths is definitely a bug to me - no matter on what layer it is causes.

Steps to reproduce the issue

Install Blender in some old version in custom directory (not the MS default place) and execute the update for the newest version as soon as it is shown in UniGetUI, the same with Zoom and plenty of others.

UniGetUI Log

Logged native task on manager Winget. Task type is LoadPackageDetails
Process start time: 21.07.2026 12:07:00
Process end time:   21.07.2026 12:07:00

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is LoadPackageVersions
Subprocess executable: "D:\Program Files\UniGetUI\pinget.exe"
Command-line arguments: " show --id "BlenderFoundation.Blender" --exact --versions --output json"
Process start time: 21.07.2026 12:07:00
Process end time:   21.07.2026 12:07:00

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is LoadPackageVersions
Subprocess executable: "D:\Program Files\UniGetUI\pinget.exe"
Command-line arguments: " show --id "BlenderFoundation.Blender" --exact --versions --output json"
Process start time: 21.07.2026 12:07:08
Process end time:   21.07.2026 12:07:08

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is ListInstalledPackages
Subprocess executable: "D:\Program Files\UniGetUI\pinget.exe"
Command-line arguments: " list --output json"
Process start time: 21.07.2026 12:07:55
Process end time:   21.07.2026 12:07:59

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Package Managers Logs

[21.07.2026 12:07:00] Loading WinGet installer metadata with Pinget. Query: Id=BlenderFoundation.Blender, Source=winget, Exact=True
[21.07.2026 12:07:00] Found 4 screenshots for package Id=BlenderFoundation.Blender
[21.07.2026 12:07:00] Loaded operation parameters for package id=BlenderFoundation.Blender on manager Winget and operation Update: update --id "BlenderFoundation.Blender" --exact --source winget --silent --include-unknown --architecture x64
[21.07.2026 12:07:00] Loaded details for package BlenderFoundation.Blender on manager Winget
[21.07.2026 12:07:08] Loaded operation parameters for package id=BlenderFoundation.Blender on manager Winget and operation Update: update --id "BlenderFoundation.Blender" --exact --source winget --silent --include-unknown --architecture x64
[21.07.2026 12:07:17] Loaded operation parameters for package id=BlenderFoundation.Blender on manager Winget and operation Update: update --id "BlenderFoundation.Blender" --exact --source winget --silent --include-unknown --architecture x64
[21.07.2026 12:07:59] Version string 1.4.4-b8d62 appears to contain non-numeric characters within a numeric segment and will be treated as unknown
[21.07.2026 12:07:59] Version string 1.4.4-b8d62 appears to contain non-numeric characters within a numeric segment and will be treated as unknown
[21.07.2026 12:07:59] Version string latest (10.34.1c) 20250213 16:03:19 appears to contain non-numeric characters within a numeric segment and will be treated as unknown
[21.07.2026 12:07:59] Version string latest (10.34.1c) 20250213 16:03:19 appears to contain non-numeric characters within a numeric segment and will be treated as unknown
[21.07.2026 12:07:59] Found 358 installed packages from Winget

Relevant information

I tried the checkboxes "as admin", "interactive" being clicked, not clicked - nothing is working.

Screenshots and videos

Update example ended with Blender 5.1.2 (old, as installed before on the wanted place) and Blender 5.2.0 on the MS default folder. Result should be that there is no more 5.1.2 on the old place and 5.2.0 being there instead ... just as updates should be.

[GabrielDuf]

Thanks for the detailed report. I can explain what's happening.

When you set a custom install location in a package's Install Options, UniGetUI passes that path during installation. On updates, however, the path is currently ignored unless Settings → WinGet → "Force install location parameter when updating packages with custom locations" is enabled.

That setting is off by default, and the Run as administrator and Interactive installation options don't affect this behavior. So the path was saved correctly and used for the initial install, but not for updates.

The reason for this toggle is an earlier issue (#4210): users who configured a global default install location found that updates were moving existing applications into that location. Making the behavior opt-in fixed that problem, but it also unintentionally affected explicit per-package install locations like yours.

Workaround: Enable that setting and run the update again.

I've already implemented a fix that will be included in the next UniGetUI release. Explicit per-package install locations will be honored during updates without requiring the global setting, while the global default install location will remain opt-in to avoid reintroducing the original issue.

[GabrielDuf]

One caveat, even when UniGetUI passes the install location to WinGet, it only works if the package's installer supports it. Portable packages and many MSI installers do, but some EXE installers ignore the target directory argument entirely. In those cases, the limitation is in the installer (or WinGet), not UniGetUI.