From cf2415cc6527cb92898694aae88fd84d54aac28c Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Tue, 29 Sep 2026 03:08:56 -0300 Subject: A failed builtin's err replaces its msg, and (xN) is a running total A builtin failing a ctl write logged its Verbose announcement, its words as a msg, and the write's err, so the same failure again never repeated the newest record and never collapsed. Its err alone is logged now (the msg is still shown and kept in +Messages). A repeat of a record a follower has read is a new line with the running total, (xN) being N in all. fs.md states both rules. Co-Authored-By: Claude Opus 5.5 --- docs/fs.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) (limited to 'docs/fs.md') diff --git a/docs/fs.md b/docs/fs.md index 428cc84c..5836215f 100644 --- a/docs/fs.md +++ b/docs/fs.md @@ -625,18 +625,22 @@ mapping the serial it had to the one it has now, and `restoredcol for every line the editor says (with `verbose` on, that includes each builtin announcing itself as it runs, on purpose: the log says which ran -- unless the builtin then says something of its own that starts with its -name, `Kill: nothing running`, which takes the announcement's place; a line -said again word for word before any follower read it is that line counted, -`msg 3 Undo: nothing to undo (x40)`, as `err` is; its serial is the pane it ran at, `-` when the keyboard was on a +name, `Kill: nothing running`, which takes the announcement's place; a +builtin that fails a ctl write is logged by that write's `err` alone, no +announcement and no `msg`, so the same failure again is the same record +again; a line said again word for word is counted, `msg 3 Undo: nothing to +undo (x40)`, as `err` is (below); its serial is the pane it ran at, `-` when the keyboard was on a column or workspace tag, or the line came to the root's ctl, `/tagexec` or a column's ctl or exec), and `err : ` for every write or truncation the tree refused or that failed -- through a mount a shell sees only the errno its kernel mapped the reply to, usually `Invalid argument`, and this is the reason (`err 3 addr: -no match for regexp`). The same err again, before any follower has read -the first, is that record counted (`err 3 addr: no match for regexp (x4)`), -so a client retrying a failing write does not push the rest out of the -ring; a follower that read it gets each repeat. Through a kernel mount a client sees only an errno, which 9ns reads from the +no match for regexp`). A record said again word for word, straight after +itself, is counted rather than repeated (`err 3 addr: no match for regexp +(x4)`: four in all, counting the first), so a client retrying a failing +write does not push the rest out of the ring. A record a follower has +already read is never rewritten: the next repeat is a line of its own +carrying the running total, `(x5)`, and counting goes on from there. Through a kernel mount a client sees only an errno, which 9ns reads from the error's words (cloud9's 9ns/src/nine.zig, `enameToErrno`): a malformed write -- an unknown or ill-formed control message, `bad address syntax`, `bad regular expression` -- is EINVAL; a lock another open holds, EBUSY; a pane -- cgit v1.3