improve comment regarding 9p Tstat compliance

fix the stat on directories For directories, f-dir->fd is *the* file descriptor associated with that directory, so doing a fstatat(f->dir->fd, f->fpath) was trying to do a lookup for f->fpath (the directory name) *inside* the directory itself. bug spotted by cage, thanks!

trailing whitespaces

use NL_TEXTMAX for the strerror_r buffer the strerror_r(3) man page mentions that it returns a message that's up to NL_TEXTMAX bytes long (including the NUL.) strerror_r can fail with ERANGE if the buffer is not large enough, and that's probably the case of some "funny" Rerrors that cage gets from time to time.

Merge branch 'main' of ssh://omarpolo.com/kamid

publish struct qid

reset readdir buffer when the client seeks back to zero

simple fix to avoid messages bigger than what we can currently handle

typo

fix tremove wrt directories we can't call unlinkat with `.' as path, so the hackish solution (but also the only viable one I can see) is to unlinkat ../<dirname>. Furthermore, calling unlinkat(f->dir->fd, f->fpath) was incorrect because f->dir->fd already points to the directory.

dis-entagle qids from the directory file descriptor I've been using the qid both as the 9p protocol element *and* as a wrapper with refcounting around a directory file descriptor. I can do better, let's split the qid struct into a "proper" qid and dir. Dir is now the wrapper with refcounting around the directory file descriptor and qid is just the 9p struct. fids are still associated with a dir, but now they store the directory name if they point to the directory. The previous pattern to detect if a fid is pointing to a dir thus changed: instead of assuming that fpath is "", look at the qid struct.

fix comments regarding fd and iomode iomode can be set to "garbage" and fd still be -1. To check if a fid was opened one _has_ to check the fd value.

clarify qid implementation: they are only wrappers around direrctory fds The bug recently found by cage is caused by twalk accidentaly reusing the file descriptor for the newly created qid from the "parent" qid (the start of the walk.) I'm considering qids as wrappers around file descriptors. This way, all the 9p actions are straigtforward to implement using the *at functions (openat, fstatat, unlinkat, ...) with only one path component. The mistake was to save the path component (a file name) inside the qid struct: this leads to confusion and prevent us from sharing qids to our heart's content. The best way to fix the problem is to correct the mistake done in the qid implementation: move the path name to the fid struct. This needs some fixes in various places. One important difference is that now we're completely leveraging the kernel for checking that clients don't open directory for writing. All tests are now passing; many many thanks to cage for the "extra" regression suite, it helped a lot in squashing the remaining bugs.

delete double return

cosmetic s/ATTR_DEAD/__dead