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>
EdnunpandClaude Opus 4.7