e1ccd674c0
Both hand-off sites pre-write the update marker: the in-app Update button (applyUpdates) and the Windows bootstrap-recovery path (handOffWindowsBootstrapRecovery). Either one can strand a user on a pre-#74782 staged installer, and the recovery path is worse — it fires when the install is already unhealthy, so a refused claim there wedges the very repair meant to heal it. Route both through stagedUpdaterSupportsPrewrittenMarker and log the skip so the reason is visible in desktop.log instead of looking like a missing write. Also document on copy_self_to_hermes_home that its --update no-op is what lets an installer-protocol change strand the entire installed base on a binary that predates it — the root enabler of this class of bug. |
||
|---|---|---|
| .. | ||
| bootstrap.rs | ||
| events.rs | ||
| install_script.rs | ||
| lib.rs | ||
| main.rs | ||
| paths.rs | ||
| powershell.rs | ||
| update.rs | ||