u9fs like to return "i/o count too large" on reads/writes that exceeds msize - 24. seems arbiratry, as in theory we should be able to issue a Tread/Twrite for msize - (HEADERSIZE + 4) = msize - 13. Don't know where the other eleven bits come from. To conclude the rant: even if a client issues a Tread/write too large, why don't just return a value smaller than requested? It's explicitly documented in the plan9 manpage for Tread.

don't use a constant: msize may be lower than that. Instead, use `msize - 4' which is guaranteed to be the maximum transferreable size. (it's not possible for msize to be lower than 4 since we reject ridiculously small msizes, so that difference can't underflow.)

Assume that if -K is not given, the file passed for -C holds the key too. This is particularly useful with the new `gencert' contrib script.

The idea behind woc_file is to create or open a file, but it's always used for writing fresh new content, so it's actually an error that it opens a file for writing without truncating it too. It means that if we write less content than what the file already has, we kepp garbage at the end. This adds an extra argument in send_fid (that is actually used only from woc_file now) so that we can pass KOTRUNC for do_open.

found by clang' static-analyzer

it leverages the recently added wstat support