a73x

layout file: guard against a wall that changed underneath (two terminals on one device)

open   by a73x

From the wall-is-the-layout branch (2026-09-02). Every wall rewrites the whole layout file on its own changes; exit-time saves were removed so a passive second terminal never writes, but two ACTIVE terminals on one device still last-writer-win each other's adds (accepted like the hosts file's read-modify-write). Follow-up: remember the file's mtime/hash at seed and refuse to overwrite a file that changed underneath, with a notice; or merge by leaf. Also from the final review: two concurrent hub '+' presses with one slot free can both pass roomForLeaf (unlocked dial) and orphan the second session.

Comments

a73x   2026-09-04 13:04

[claude 2026-09-04] Live instance, severe. A wall inside a mosh-server session (started ~09:00) sat
untouched for 4h49m while the user's real wall added sessions 7 and 1 and I
migrated four leaves from alex@192.168.0.207 to .208. At 13:45:15 the mosh wall
persisted its in-memory tree — five leaves, all .207 — over the seven-leaf file,
one second after the user's restarted wall had seeded from it. The user's
question was "all my claude sessions locally are gone?". Nothing on either
screen said a second wall existed; ps did. The stale wall never read the file
again after start, so "changed underneath" here means hours, not a race.
A generation stamp in the file that a wall must have READ before it may
WRITE would have refused this save.

a73x   2026-09-04 13:10

[claude 2026-09-04] Live instance, severe. A wall inside a mosh-server session (started ~09:00) sat
untouched for 4h49m while the user's real wall added sessions 7 and 1 and I
migrated four leaves from alex@192.168.0.207 to .208. At 13:45:15 the mosh wall
persisted its in-memory tree — five leaves, all .207 — over the seven-leaf file,
one second after the user's restarted wall had seeded from it. The user's
question was "all my claude sessions locally are gone?". Nothing on either
screen said a second wall existed; ps did. The stale wall never read the file
again after start, so "changed underneath" here means hours, not a race.
A generation stamp in the file that a wall must have READ before it may
WRITE would have refused this save.