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.

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.

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.

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.

A walk of zero paths is used to duplicate a fid. it doesn't make sense to reply with a body containing the qid relative to the file, because it's not a real walk, it's just a duplication. Furthermore, it would break the expectations that the number of qid returned is less or equal to the walked components.