From c0302211818a95acb7a276abdba7a32eac2358d5 Mon Sep 17 00:00:00 2001
From: Gabriel Schneider <gbrls@0x4200.cafe>
Date: Mon, 28 Sep 2026 17:16:55 -0300
Subject: pardes builds against cloud9 2a7137c, whose 9ns reads a reply that
 came in before a hang-up

9ns failed every waiting call as soon as one send met a closed socket, so an answer the server sent just before hanging up could be lost: the Restore write's, when pardes cuts its connections. The docs no longer say the Restore write usually fails through a mount; only an older 9ns could, and the log stays the authority.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 docs/fs.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'docs')

diff --git a/docs/fs.md b/docs/fs.md
index 86f44501..445aa725 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -117,9 +117,9 @@ asks the same first -- `Dump` writes `pardes-<date>-<time>.zon` (UTC) in
 and logs `dump <path>`, 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 (through a 9ns mount the write usually fails with
-ECONNRESET all the same: 9ns fails a request whose reply is already in once
-the hang-up breaks its next send, so trust the log): dial again, and the new
+editor's panes (a 9ns older than cloud9 2a7137c could fail the write with
+ECONNRESET all the same, when another request's send met the hang-up
+before the answer was read; the log is the authority): dial again, and the new
 log names the restored panes and
 `restore <path>`. The answer has 200 ms to leave before the cut, so a slow
 client may see only the cut; the log's `restore <path>` is what says the
-- 
cgit v1.3