[thomasjm]

A client writing invalidation paths to stdin has no way to tell when one has taken effect: the write only reports that the path was queued. A client that orders work after an invalidation — re-reading a file it expects to have changed — races the notifications.

A request is now inval <id> <path>, and gets exactly one reply on stdout: ok <id> once that path's inval_entry and inval_inode have been issued, or err <id> <reason> if the path could not be decoded, so a client always learns the outcome rather than waiting out a timeout. A path that resolves to nothing is still applied and replied to, since that is the ordinary case for a delete or a rename. The id means a client matches a reply to the request that produced it instead of relying on position, and the tag means anything else that ever reaches stdout is not mistaken for a reply.

The path is percent-encoded, decoded here with percent-encoding — a filename may contain the newline that ends a request, and nothing on a Linux filesystem forbids it. The crate brings no further dependencies. The unit tests pin the encoded forms a client is expected to send, since the encoder is a separate library in a separate language.

A line with no inval prefix is still read as a bare unencoded path and replied to with ok <path>, so a client that predates this keeps working.