Re: [fuse-devel] vanished files after rename

[Wolfgang B. <w.b...@pr...>]

> > or the kernel needs to make the combination of
> > lookup+open atomic, or the "hidden-file" hack needs to be improved (if
> > you just remove the is_open() checks you end up moving from ENOENT to
> > EBUSY because it performs multiple actions which each lock and unlock
> > rather than taking one big lock over the entire process which would
> > seem more reasonable).
> 
> Possibly doable.  The problem is: we only get FORGET when the kernel
> flushes the inode from the cache for some reason.  This event can only
> happen after all references to the dentry and inode  inside the kernel
> have been dropped, but it won't happen immediately after that,
> possibly only after a very long time (if the cache is large and the
> kernel doesn't feel the need to free up the memory associated with the
> cached structures).
> 
> What we really need here is some indication about the case when the
> inode/dentry is not just sitting in the cache, but there's an active
> reference to either at the point of unlink/rename.  Only in that
> relatively rare case do we need to extend the hidden-file hack.

Not rare enough ;-)
I'm not sure we can actually distinguish between these two cases
within fuse, since the lookup() call doesn't really tell you why it
is happening. And the deletion apparently comes after the lookup() but
before the open().
One possibility - having the hidden-file hack last all the way
from lookup() to forget() - seems a bit drastic though. (As in mark
it as `to-be-hidden-if-deleted` at lookup() and `free-to-discard`
at forget(). If the forget() happens to come only after a long delay
this would feel really ... inconvenient.)