I've done some digging from the client side. As is mentioned in Miklos' original patch (which appears to have been shot down) the higher level implementation appear to be broken for this. Here's what the code looks like for fstat in fs/stat.c: int vfs_fstat(unsigned int fd, struct kstat *stat) { struct fd f = fdget_raw(fd); int error = -EBADF; if (f.file) { error = vfs_getattr(&f.file->f_path, stat); fdput(f); } return error; } In other words, it only uses the open fd to derrive a path and then executes the getattr off of that path. If that path no longer exists (because of unlink or remove) then you are hosed. In my understanding, the "work around" I suppose is the so-called 'silly renaming' where remove/unlink simply does a rename until all open instances are closed. The frustrating thing is that the 9p protocol is setup to work off of the fid, which maps to the fd -- so its perfectly capable of the original semantic but the high level code in fs/stat.c only wants to give a path. I can do a work around on the client where a getattr "favors" open fids for the operation or I can do the sillyrename hack that NFS and CIFS has used but both of those look god-awful. -eric On Fri, Apr 10, 2015 at 7:30 AM, Mark Glines