The self-contained-service change broke the old self-update: the service used to run in
the app's own folder and restart onto a newer RemSound.exe that landed "next to it";
now it runs from its own ProgramData copy, so it never saw the app's new build.
Rework: at install/update the service records the app's folder (ServiceStore app-source
path, written elevated so the SYSTEM account can read it). The service's existing 45s
update poll now watches THAT folder; when the app's auto-updater drops a strictly-newer
RemSound.exe there, the service (as SYSTEM) copies the new build into its own bin and
restarts onto it via the detached restarter script. All SYSTEM-side: no UAC, no user
action. Loop-safe (strictly-newer only; bin == app version after the copy).
So a real release (version bump) propagates to the service automatically. Same-version
dev rebuilds don't trip the strictly-newer check -- the Service menu "Update service to
this version" forces those.
Trust posture unchanged from the old in-place scheme (SYSTEM copies from a user-writable
folder); noted in the class doc for a future code-signed hardening.
New self-test coverage: app-source path round-trip + "no readable app version => no
update" (never act on uncertainty). Gate: 40/40.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed wants logging for the service updating.
- New ALWAYS-ON update log at ProgramData\RemSound\service\update.log (not gated on the
service-logging toggle - updates are rare but important). It records the full sequence:
* "update detected: newer RemSound.exe (5.3) found, running 5.2 - restarting"
* the restarter's own "stopping" / "service started" (or "START FAILED - <reason>")
* "update complete: now running version 5.3"
The restart PowerShell writes its stop/start outcome itself, so the part that runs AFTER
the old service process is gone - and any failed start - is still captured. A pending
marker set at detection and consumed on the next start closes the loop (its absence flags
a stuck update).
- Service menu gains "View service update log" to open it (friendly message if none yet).
Update log + pending-marker round-trip covered by the isolation self-test. Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Local checkpoint - NOT for public release. Ed: an update should tear down the service,
update it, and restart it. It didn't - the updater has no service awareness.
Current (unchanged, verified correct): the auto-updater renames the install files aside
and copies the new ones in, which a running service TOLERATES (no failed swap). The old
version keeps streaming; the new files sit in place.
New: the service now adopts the update itself. Because it runs as SYSTEM (which has the
rights the non-elevated updater lacks), a 45s timer notices when a strictly-newer
RemSound.exe has landed next to it and restarts itself onto the new binary (detached
PowerShell Stop-Service+Start-Service). Loop-safe: only fires on a strictly-newer on-disk
version; any uncertainty (file mid-swap, unparseable version) means don't restart, and
after the restart on-disk == running so it never re-triggers.
Test "Service registration args" now also covers the version-comparison logic (newer =>
restart; same/older/missing => no restart). Gate 27/27.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EdnunpandClaude Opus 4.8