mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-09-07 15:07:17 +00:00
Tobias GesellchenandClaude Sonnet 5
ec340847f2
The gzip fix in the previous commit only helps once a backup is being made; it doesn't address the actual moment that broke on real hardware: the cross-device mv/copy of the new binary into place ran out of space mid-write, leaving a truncated, non-executable binary as the live one. UBIFS is a log-structured flash filesystem, so space "freed" by overwriting the old binary isn't guaranteed reusable in time for the new one to land -- this happened on a device with 15.7MB available against a ~14.8MB binary. Add a preflight check before downloading anything: fetch the new binary's real size via a HEAD request (adapts automatically as binaries grow, instead of a threshold that goes stale every release) and compare against available space plus a flat 5MB safety margin. - Comfortably enough room for old + new + a compressed backup: proceed exactly as before, silently. - Enough for old + new but not enough extra for a backup: warn interactively and require explicit confirmation before proceeding without one. Reads from /dev/tty since the script is normally piped via `curl | sh` (stdin is consumed by the script itself). Defaults to the safe choice (abort) on empty input, matching the [y/N] prompt. AFTERTOUCH_FORCE_NO_BACKUP=yes overrides for non-interactive/scripted use. - Not enough room even for the replace itself: abort before starting the download, rather than attempting a doomed download/replace that could leave a truncated live binary. - No TTY available and the operator didn't set the override: abort rather than silently guessing. - HEAD request fails for any reason: skip the check with a warning rather than blocking the install on it. Verified: all five decision branches (plenty of room, warn+decline, warn+confirm, warn+forced-override, hard abort) produce the correct result under both dash and a real BusyBox v1.38.0 container, including the gzip/gunzip streaming backup and glob-based pruning from the previous commit. The HEAD-request size lookup was separately verified against a live GitHub release URL with real curl -- catching and fixing a bug where naively taking the first "content-length:" header grabbed the 302 redirect's (0), not the actual asset's, size. Not yet re-tested end-to-end on real hardware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>