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 <[email protected]>

1 files changed, 3 insertions, 3 deletions

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