ftp: issue slightly smaller requests to please u9fs 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.

ftp: allow user@host syntax; guard against empty user or port

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

ftp: fix Rstat parsing as per recent change on kamid

make -C and -K imply -c

ftp: allow only -C for file with both cert and key inside 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.

new command pipe: fetch data and pass it as stdin of a program

fetch_fid: return int instead of exiting on write(2) errors

ftp: truncate the file in woc_file 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.

fix memory leak in walk_path error path found by clang' static-analyzer

fix ls: don't hardcode fid=1

ftp: add nextfid to find the next lower free fid

add `rename' command it leverages the recently added wstat support