Repository navigation
v2.24.2
Updates that can't jam, from either direction
One fix, aimed at the worst update failure we've seen: the updater could deadlock itself holding the install folder — a child of Nex inheriting its file handles, then failing its own backup move with "in use by another process" (the other process was itself). The updater now launches with a clean handle table, waits for Nex's web renderers to finish tearing down, and retries longer before giving up.
GitHub release title: exactly v2.24.2 (version only, no descriptive suffix — the descriptive title lives in this body heading).
What changed
- Updater no longer trips over itself: the update launch uses a direct system call with handle inheritance disabled, so nothing Nex holds can leak into the updater and block the install-folder backup. Previously this exact shape caused a persistent, unretryable failure on some machines.
- Waits for a quiet tree before moving: after stopping Nex, the updater gives Nex-owned WebView2 renderer processes up to 10 seconds to exit (matched strictly by our own data-dir path — shared renderers belonging to Edge, Teams, or Office are never touched), then retries a blocked backup move 6 times over ~12 seconds instead of 3 over ~3.
- Failed updates still name names: keeps the previous release's Restart Manager forensics — every blocked attempt logs the locking process and PID.
Bug Fixes
- Update failed with "file in use by another process" despite Nex being stopped: fixed as above. If it ever recurs,
updater.login the update work dir identifies the holder.
Commit Log
5b85c5efix(updater): non-inheriting spawn, WebView2 quiesce, longer backoffc4c6961chore(release): bump to v2.24.2