report the correct write length

limit IMSG_BUF_CONT size by the maximum allowed by imsg

do optimal (i.e. maximum) reads and writes

cmd_ls: fix read size 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.)

reject ridiculously small msizes

fflush stdout in hexdump

allow jumbo reads

allow Tread to fill a message a message of `msize' len is valid, we just need to make sure to _not_ overflow it.

allow jumbo Twrites for real

typo

sync changelog

fail on "jumbo" requests (except for Twrite) except for Twrite, all other requests are passed via a single imsg. We don't handle "jumbo" request for anything outside Twrite, nor it does make sense actually, so let's drop it. (well, for Twstat an argument can be made, maybe)

proper err handling for parse_message

allow Twrite with size bigger than ~16K Until now I've been using a single imsg to handle each messages and the imsg framework has a limit of around 16K for message. For almost all requests, this is fine. Except for Twrite and Tread. This is an attempt to make Twrite handle bigger buffers. The listener process just looks at how big a request is and split it up in multiple messages and the client process tries to remember the fid, position and missing data to continue the write. This means that a single Twrite can be split up in multiple write(2)s.

sync changelog