[Enhancement]: About - In-place self-update overwrites the old executable with no way back

[laurentiu021]

Problem

The updater's safety story covers interruption, not badness. UpdateApplier.ApplyCopy stages the new build to targetExe + ".new" then File.Move(staging, targetExe, overwrite: true) (UpdateApplier.cs:85-91). The previous executable is destroyed by that move and never preserved anywhere. The docs are precise about what this protects against and it is not this: UpdateApplier.cs:24-27 promises only that "an interrupted copy can never leave a half-written (unlaunchable) executable at the target path", and SECURITY.md:113-116 likewise says "a staged atomic file move, so an interrupted update cannot leave a half-written, unstartable binary". Both are true. Neither helps the user whose update succeeded into a build that doesn't work. The comment at UpdateApplier.cs:114-115 ("If the swap fails the original executable is left untouched ... so a failed update can never brick the install") is about swap failure only - after a successful swap there is no original left. Given this project has shipped two launch-blocking regressions (CHANGELOG.md:1753, :2012), the scenario is not hypothetical, and the app's own design philosophy is snapshot-based reversibility for every system change (SECURITY.md and the Restore Point flow, e.g. PerformanceViewModel.cs:470) - the updater is the one mutation that isn't reversible.

Proposed solution

Preserve exactly one generation, in the folder that already exists for update artifacts rather than beside the portable exe (keeping the single-portable-file identity intact). In ApplyCopy, before the move at UpdateApplier.cs:91, copy the current target into %LOCALAPPDATA%\SysManager\updates\SysManager-previous.exe (the same directory UpdateService.cs:155-157 already creates and documents). Then expose it: in AboutViewModel, add a CanRollBack observable driven by that file's existence and a RollBackCommand that reuses the existing, already-hardened applier path - UpdateApplier.BuildArguments(currentExe, pid) + Process.Start (mirroring AboutViewModel.cs:574-584) with the previous binary as the source. Render it in AboutView.xaml as a SecondaryButton inside the version card (AboutView.xaml:44-64), labelled in plain language for the persona: "Go back to the previous version (v1.56.3)". Exclude SysManager-previous.exe from the cache-pruning pattern proposed in the sibling cache finding.

Rationale

An auto-updater without a downgrade path is a single point of failure for the entire installed base that doesn't use winget: winget users can winget install --version, but an in-app updater user has no local copy and must work out on their own that they need to find an older GitHub release. For the target persona that is a dead end - she cannot navigate a releases page and pick a prior tag. One retained generation plus one button converts "my PC tool stopped opening" into a single click, and it aligns the updater with the reversibility contract every other mutating feature in the app already honours.

Evidence

UpdateApplier.cs:85-91 (staging + File.Move(staging, targetExe, overwrite: true) - no preservation of the outgoing binary); :24-27 and :114-115 (the interruption-scoped guarantees, quoted above); SECURITY.md:113-116 (same scope). Update-artifact directory already exists: UpdateService.cs:155-158, created at :193. Existing applier invocation to reuse: AboutViewModel.cs:574-584 (BuildArguments(currentExe, pid) + Process.Start(... UseShellExecute = true)). Reversibility norm elsewhere: PerformanceViewModel.cs:470 restore-point confirmation. Historic launch-blocking releases: CHANGELOG.md:1753, :2012. No rollback surface exists today - grep -rni "rollback|roll back|previous version" SysManager/SysManager --include=*.cs --include=*.xaml returns only DNS/hosts snapshot logic (DnsHostsViewModel.cs:37, :184; HostsFileService.cs:39) and a DeepCleanup string, nothing about the app's own binary.

Risk / trade-off

Adds one file (~the size of the app) under %LOCALAPPDATA%, which is exactly what the sibling pruning finding is trying to bound - the two must land together so retention is "current + one previous", not unbounded. Rolling back re-exposes whatever bug the newer version fixed, so the button needs a confirmation via DialogService.Instance.Confirm naming the version being restored. Rollback must not fight the update banner: after a rollback the startup check will immediately re-offer the newer build, so consider suppressing the banner for the version just rolled back from (otherwise the user is nagged straight back into the broken build).

Affected area

About

---

Effort: M | priority: value 3/5, fit 3/5
Identified during the trust, distribution and reach audit audit.

[laurentiu021]

Implemented in v1.61.0 (PR #1765), essentially as proposed.

Your framing was the convincing part: the docs were precise about what the atomic move protects against, and that scope simply doesn't cover the case where the update succeeds into a build that doesn't work. Two launch-blocking releases in this project's history makes it a real scenario, and the updater really was the one mutation without the reversibility every other system-touching feature honours.

What shipped

• PreserveCurrentBuild copies the outgoing binary to %LocalAppData%\SysManager\updates\SysManager-previous.exe before the move — the existing update-artifact folder you pointed at, so the single-portable-file identity stays intact.
• CanRollBack + RollBackCommand on AboutViewModel, rendered as a SecondaryButton in the version card, visible only when a retained copy exists so it can never be a button that does nothing.
• It reuses the already-hardened applier path — BuildArguments(currentExe, pid) + Process.Start — exactly as you suggested, rather than a second file-copy implementation that wouldn't have the wait-for-exit / retry-while-locked / atomic-move properties.
• DialogService.Instance.Confirm first, naming the consequence: rolling back re-exposes whatever the newer build fixed.

The sibling-finding coupling you flagged

You were right that this and the pruning bound have to land together, and it was sharper than "should": SysManager-previous.exe matches PruneOldDownloads' SysManager-*.exe pattern, so the very next update download would have deleted the rollback copy — silently, since pruning is best-effort and logs at Debug. Now explicitly excluded, with a test that also asserts a genuinely stale file still gets pruned.

Retention is bounded to exactly one generation: each copy overwrites the last, so it can't accumulate full-size executables.

Retaining is best-effort. If the folder can't be written, the update still proceeds — a safety net that can't be stretched must not abort the update. There's a test that plants a file where the updates directory should be, so CreateDirectory fails, and asserts the update completes anyway.

Verification

Harness against unfixed main: 8 failures, 2 passes. Both passes are controls — a failed copy still leaves the working exe intact, and the staging file is still moved rather than left behind. The interruption guarantee predates this change and had to survive it. Branch: 10/10. 11 new tests.

SECURITY.md and README's update section both described a one-way update; both now document the retained generation, where it lives, that only one is kept, and that retention is best-effort.

Two things deliberately not done

Suppressing the update banner for the version just rolled back from. You flagged this and you're right that the user could be nagged straight back into the broken build. It needs its own state (remembering a "declined version") and its own decision about how long that suppression lasts — bundling a persisted-preference change into this PR would have made it two features. Worth a separate issue if the situation ever arises in practice.

Naming the version in the button label ("Go back to v1.56.3"). The retained file's version isn't read — it would mean loading the PE version block of a second binary at About-tab construction time. The label says what it does instead; the confirmation dialog carries the explanation.

Needs eyes on the secondary workstation for the true end-to-end check: install an update, confirm SysManager-previous.exe appears, press the button, confirm the older version comes back.