EdnunpandClaude Opus 4.7
9a5c46eecf
v1.2's self-updater silently failed when the install folder lived inside a Dropbox sync path. Dropbox held write locks on the existing RemSound.exe / DLLs during the brief window between the parent exiting and the helper script copying the new files in. The helper's robocopy (/R:5 /W:1) gave up after 5 seconds, and the helper then unconditionally relaunched the OLD binary — so the user saw the same version they started with after pressing "Yes" on the install prompt, with no visible error. Helper script (BuildInstallScript) changes: * Robocopy retries bumped to /R:60 /W:1 — up to 60 seconds per file. Dropbox lock release happens reliably within that window in practice. * Robocopy exit code is captured and checked. Codes >= 8 are real failures. On a failure the helper writes update-failed.txt to the install folder with the cause + recovery steps, leaves the staging folder intact, and does NOT relaunch the old binary. Earlier versions silently relaunched the unmodified old binary, hiding the failure. * Helper appends a step-by-step trace to _update-helper.log (in the install folder), with robocopy's own output included via /LOG+:. * update-failed.txt, _update-helper.log, and _apply-update.cmd are added to the /XF exclusion list so the helper's own state files don't get copied to themselves on a repeat update run. DownloadAndStageInstallAsync also clears any stale update-failed.txt at the start of every new attempt, so a successful run leaves the install folder clean. readme.html "If install fails" section expanded with the new update-failed.txt marker file behaviour and the _update-helper.log location. Wire format, audio pipeline, and recording feature unchanged from v1.2 — this is updater-machinery-only. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1.8 KiB
1.8 KiB
RemSound v1.3
Updater hardening for Dropbox-installed copies. The wire format, audio pipeline, and recording feature are unchanged from v1.2.
What's fixed
The v1.2 self-updater silently failed on installs inside Dropbox-synced folders. The cause: Dropbox held write locks on the existing RemSound.exe / DLLs during the brief window between the parent process exiting and the helper script copying the new files in. Robocopy gave up after 5 seconds, and the helper unconditionally relaunched the old binary regardless — so users saw the same version they started with after pressing Yes on the install prompt.
What's new
- Robocopy retries bumped to 60 seconds per file (was 5). Dropbox lock release happens reliably within that window in practice.
- Helper checks robocopy's exit code. On a true failure (exit code 8+), the helper writes
update-failed.txtnext toRemSound.exewith the cause and recovery steps, and does not relaunch the old binary. Earlier versions silently relaunched the unmodified old binary, hiding the failure. - Helper writes a step-by-step log to
_update-helper.login the install folder. If a future update goes wrong this is the trace. - Stale failure markers are cleared at the start of every new update attempt, so a successful run leaves the install folder clean.
Install
- Download
RemSound-v1.3.zipfrom this release. - Extract somewhere with write permission (e.g.
C:\RemSound\,Documents\RemSound\, etc.). AvoidProgram Filesunless you grant write permission so the self-updater can replace files in place. - Run
RemSound.exe. Allow on private networks when Windows Firewall prompts. - Press F1 (or use the Help menu) for the user manual.
Requires the .NET 10 Desktop Runtime. If it's missing, Windows offers to fetch it on first launch.