work around wstat limitation the previous commit added an explicit check for extra data in messages. The problem is that wstat voluntarily skips reading some fields at the end, so the len will always be greater than zero!

fail if the received packet is too long This adds extra checks to every t* function: if the client sent too much data per message, treat is an a protocol violation and terminate the connection. Regress suite still passes, this is just an extra safety check for finding wrong clients implementations. The twrite function was the only one with a check like this.

fix np_read{8,16,32,64} functions they should return 0 on failure, not -1

kamid: change fid fname size to NAME_MAX the fname field is just the file name, so NAME_MAX is more appropriate. Committing this separately from the rename change so it's easier to roll back eventually.

kamid: rename field fpath to fname it's actually just the file name, not a path

fmt

ftp: document rename

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

9pclib: add wstat support

fmt

kamid: add wstat it's not exactly compliant, as 9p requires the changes to be done atomically, but it's not possible to better targeting a UNIX file system. The 9p manpage regarding wstat isn't clear about the behaviour when changing the name of the file: kamid changes the associated fid to reflect the rename. kamid also allows to rename files to other directories, the fid is updated to the new location even in this case.

move struct np_stat to kami.h

ftp: print mtime in ls output Print the time (HH:MM) of the last edit is within the last 6 months, the year otherwise; match what `ls -lahF' does on OpenBSD, and I think it's cool.