Repository navigation
1.2.1: Make the handover actually happen
1.2.0 shipped a self-update that did not work. This fixes it. If you are on 1.2.0, you will need to download this one by hand: that is precisely the bug.
| Download | What it is |
|---|---|
DontLeaveUpdatesToFate-1.2.1-portable.exe |
Single file. Run it from anywhere, installs nothing. |
DontLeaveUpdatesToFate-1.2.1-setup.exe |
Normal installer: Start Menu entry, Add/Remove entry, installs to C:\Program Files\VagueDustin Enterprises. |
x64, Windows 10 1809 or newer. Both unsigned: SmartScreen will warn on first run; More info → Run anyway. SHA256SUMS-1.2.1.txt is attached.
What was broken
Both self-update and "Restart as admin" closed the window and did nothing. Neither reported an error, because by the time they fail the app is already gone. Both were found by running them, not by reading the code.
Three separate faults, stacked on each other.
1. The helper never started on the portable build
Both features work by leaving behind a small PowerShell helper that waits for the app to exit and then does something to the files the app was using. A detached spawn is enough from the installed build and is silently not enough from the portable one, which is a stub that extracts the app to a temp directory and tears it down afterwards. detached: true governs the console and the process group; it does not confer independence.
"Restart as admin" has been broken on the portable build since 1.0.0. It was only ever tested on an installed copy.
The fix is not "use the right mechanism": it is to stop trusting them. handover.ts now tries Start-Process, then WMI, then the detached spawn, and accepts none of their return values: the helper's first statement writes a marker file, and a mechanism only counts once that file exists.
That distinction is the entire bug. Win32_Process.Create returns 0 and a process id for a process that executes nothing at all.
2. The portable swap waited for the wrong thing
It waited for the app to exit, then retried the copy four times a second apart. But the stub outlives the app, and while it is deleting its extraction its own image is still mapped and the exe cannot be written. It now waits for the condition a copy actually needs (an exclusive write handle on the target) for up to ninety seconds, polling twice a second.
3. The installer could not be launched from where it was downloaded
%APPDATA% is where a great deal of real malware stages itself, so a hardened Windows refuses to execute anything from there. The installer downloaded and verified perfectly, then failed to start with "the system cannot find the path specified", for a file that Test-Path confirmed existed. The same file ran fine from two other directories.
Downloads now go to your Downloads folder, which is where an installer would have been if you had fetched it yourself, and the least likely place to be treated as suspicious.
And when it goes wrong anyway
Every handover attempt is now recorded in %APPDATA%\dont-leave-updates-to-fate\updates\handover.log: which mechanism was tried, what it claimed, and whether the helper actually ran. An installer that will not start opens Explorer with the file selected rather than leaving you looking at a closed window.
Housekeeping
- A successful install removes the downloaded installer, and being up to date clears any stale one.
- That cleanup runs in your Downloads folder, so it only ever deletes files matching this app's own artifact names (
DontLeaveUpdatesToFate-<version>-setup.exeand-portable.exe). A cleanup routine loose in someone's Downloads folder is a catastrophe rather than a bug, and there is a test whose only job is to keep that pattern honest. - 17 new tests covering the two handover scripts and the deletion pattern. 243 in total.
Licence
Free software under the GNU AGPL v3 or later, with absolutely no warranty. Copyright © 2026 VagueDustin Enterprises.