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>
24 lines
1.8 KiB
Markdown
24 lines
1.8 KiB
Markdown
# 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.txt` next to `RemSound.exe` with 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.log` in 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
|
|
|
|
1. Download `RemSound-v1.3.zip` from this release.
|
|
2. Extract somewhere with write permission (e.g. `C:\RemSound\`, `Documents\RemSound\`, etc.). Avoid `Program Files` unless you grant write permission so the self-updater can replace files in place.
|
|
3. Run `RemSound.exe`. Allow on private networks when Windows Firewall prompts.
|
|
4. 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.
|