From faca1504a2296fba9631c45c9f01f3c252cbd0d8 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Mon, 28 Sep 2026 13:51:15 -0300 Subject: docs: the log's restore record, not the Restore write's answer, says a Restore happened The answer gets 200 ms to leave before the connections are cut, so a slow client may see only the cut; the new log's 'restore ' record is what to trust. Co-Authored-By: Claude Opus 5.5 --- docs/fs.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/fs.md b/docs/fs.md index ae5e27ad..7361c19e 100644 --- a/docs/fs.md +++ b/docs/fs.md @@ -116,7 +116,9 @@ and logs `dump `, and `Restore` with no path takes the last one; a Restore puts a new editor under every client, so the write of it is answered and then every connection is hung up, their fids naming the old editor's panes: dial again, and the new log names the restored panes and -`restore `. Keeping connections across it would mean carrying serials +`restore `. The answer has 200 ms to leave before the cut, so a slow +client may see only the cut; the log's `restore ` is what says the +Restore happened. Keeping connections across it would mean carrying serials and opens into the new editor, which acme, whose Load only adds windows, never needed); and `Kill`, which does not quit but stops commands, as acme's does: bare, every command pardes -- cgit v1.3