Re: [Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Apr 12, 2015 at 12:42:35PM -0000, Eric Van Hensbergen wrote:

> 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.

What do you mean, "no longer exists"?  Don't confuse path with pathname -
it's a mount,dentry pair.  And dentry in question bloody well ought to still
have the FID associated with it - you shouldn't use the same FID for
TREMOVE and for TREAD/TWRITE.  TREMOVE clunks the FID passed to it; on
some servers you really have no choice - server discards the file completely
and on any FID that used to refer to it you get an error from that point on.  
On those you'd really have to do something like sillyrename - the only
way to keep IO going for a file sitting on such server is to have it
visible somewhere.  Normal fs(4) is that way; e.g. u9fs(4) isn't - there
FID maps to opened file descriptor on host and TREMOVE on another FID
doesn't break it, as long as host supports IO on opened-but-unlinked files.
I don't remember where qemu 9pfs falls in that respect, but I'd expect it
to be more like u9fs...

Which FID are you passing to server on unlink()?