Brief description
Installing Flori Input 1.4.0 (Flowersauce.FSClicker) with WinGet 1.29.360 fails with installer exit code 1. Running the exact same cached installer directly from a normal, non-elevated PowerShell terminal with --silent succeeds.
A Process Monitor capture shows a directory sharing conflict between winget.exe and the Velopack setup process. This may be related to #6520, but the failure stage is different: here the installer starts successfully and fails when changing its working directory. I have not tested an older WinGet version, so I cannot independently confirm a regression window.
Steps to reproduce
From a non-elevated PowerShell terminal:
winget install --id Flowersauce.FSClicker --exact --source winget
To obtain the installer error:
winget install --id Flowersauce.FSClicker --exact --source winget --override "--silent --verbose --log $env:TEMP\Flori-Input-winget.log"
Both fail with exit code 1 on this machine. Directly invoking the same cached EXE succeeds:
& "$env:LOCALAPPDATA\Temp\WinGet\Flowersauce.FSClicker.1.4.0\Flori-Input-v1.4.0-windows-x64-setup.exe" --silent
Direct invocation with --silent --verbose --log ... also succeeds and its log ends with Installation completed successfully!.
Expected behavior
WinGet should be able to launch the installer without a directory handle sharing conflict preventing installer initialization.
Actual behavior and installer log
WinGet verifies the cached installer hash, launches it, then reports exit code 1. Velopack 0.0.1298 logs:
Starting Velopack Setup (0.0.1298)
Silent: true
Verbose: true
Install To: None
[ERROR] An error has occurred: 另一个程序正在使用此文件，进程无法访问。 (os error 32)
The error means "The process cannot access the file because it is being used by another process."
Process Monitor evidence
All events below refer to this directory (user-specific path normalized):
%LOCALAPPDATA%\Temp\WinGet\Flowersauce.FSClicker.1.4.0
| Time |
Process / PID |
Operation |
Result |
Relevant details |
| 14:18:22.4102586 |
winget.exe / 22116 |
CreateFile |
SUCCESS |
Desired Access: Read Data/List Directory, Read Attributes, Delete, Synchronize; Disposition: Open; Options: Synchronous IO Non-Alert, Open Reparse Point; ShareMode: Read, Write |
| 14:18:22.7400075 |
Flori-Input-v1.4.0-windows-x64-setup.exe / 11164 |
CreateFile |
SHARING VIOLATION |
Desired Access: Execute/Traverse, Synchronize; Disposition: Open; Options: Directory, Synchronous IO Non-Alert; ShareMode: Read, Write |
| 14:18:22.7433306 |
winget.exe / 22116 |
CloseFile |
SUCCESS |
Directory handle closed after installer failure |
Interpretation: WinGet holds a directory handle with DELETE access. The installer's directory open does not include FILE_SHARE_DELETE, which conflicts with that existing access. Direct invocation after WinGet exits no longer encounters this conflict.
The failure location matches Velopack's startup code: immediately after logging Install To, it calls env::set_current_dir(containing_dir)?. The failing log never reaches the subsequent OS information message:
https://github.com/velopack/velopack/blob/0.0.1298/src/bins/src/setup.rs#L85-L97
The same directory-change call remains in Velopack 1.2.0, but I have not repackaged or tested that version:
https://github.com/velopack/velopack/blob/1.2.0/src/bins/src/setup.rs#L124-L132
Environment
- WinGet: 1.29.360
- Windows: Windows 11 Enterprise, 10.0.26200.9445, x64
- Package: Flowersauce.FSClicker 1.4.0 (Flori Input)
- Installer: Velopack 0.0.1298, per-user installation
- WinGet and direct installer invocation use normal user permissions; only ProcMon was elevated for capture.
- Microsoft.VCRedist.2015+.x64 14.51.36247.0 is already installed and recognized by
winget list --id Microsoft.VCRedist.2015+.x64 --exact.
Could you investigate whether WinGet needs to retain DELETE access on the installer directory while the child installer runs, or whether there is a supported compatibility approach for installers that set their working directory to that location?
Brief description
Installing Flori Input 1.4.0 (
Flowersauce.FSClicker) with WinGet 1.29.360 fails with installer exit code 1. Running the exact same cached installer directly from a normal, non-elevated PowerShell terminal with--silentsucceeds.A Process Monitor capture shows a directory sharing conflict between winget.exe and the Velopack setup process. This may be related to #6520, but the failure stage is different: here the installer starts successfully and fails when changing its working directory. I have not tested an older WinGet version, so I cannot independently confirm a regression window.
Steps to reproduce
From a non-elevated PowerShell terminal:
To obtain the installer error:
Both fail with exit code 1 on this machine. Directly invoking the same cached EXE succeeds:
Direct invocation with
--silent --verbose --log ...also succeeds and its log ends withInstallation completed successfully!.Expected behavior
WinGet should be able to launch the installer without a directory handle sharing conflict preventing installer initialization.
Actual behavior and installer log
WinGet verifies the cached installer hash, launches it, then reports exit code 1. Velopack 0.0.1298 logs:
The error means "The process cannot access the file because it is being used by another process."
Process Monitor evidence
All events below refer to this directory (user-specific path normalized):
Interpretation: WinGet holds a directory handle with DELETE access. The installer's directory open does not include FILE_SHARE_DELETE, which conflicts with that existing access. Direct invocation after WinGet exits no longer encounters this conflict.
The failure location matches Velopack's startup code: immediately after logging
Install To, it callsenv::set_current_dir(containing_dir)?. The failing log never reaches the subsequent OS information message:https://github.com/velopack/velopack/blob/0.0.1298/src/bins/src/setup.rs#L85-L97
The same directory-change call remains in Velopack 1.2.0, but I have not repackaged or tested that version:
https://github.com/velopack/velopack/blob/1.2.0/src/bins/src/setup.rs#L124-L132
Environment
winget list --id Microsoft.VCRedist.2015+.x64 --exact.Could you investigate whether WinGet needs to retain DELETE access on the installer directory while the child installer runs, or whether there is a supported compatibility approach for installers that set their working directory to that location?