From: Bryan G. <br...@gr...> - 2011-09-13 22:49:34
|
I am trying to implement internal removal of a directory tree from inside a fuse application (i.e., the tree reflects an internal dynamic topology created by the application, and cannot be modified externally, sort of like sysfs), but I am seeing fuse using inodes that should have been marked as invalidated (because they were "removed" by the application). I'd like to know if I am using the invalidation routines incorrectly. The behavior is pretty much identical to what is described here, in which fuse does not seem to respect the reply to a lookup: http://comments.gmane.org/gmane.comp.file-systems.fuse.devel/9523 Specifically, I have a directory structure that looks something like this: root (ino=1) subdir1 (ino=2) subdir2 (ino=3) subdir3 (ino=4) I issue fuse_lowlevel_notify_inval_entry(parent_ino=2,name="subdir2") Later, I see a lookup request come in from fuse, for which I return an error: lookup(parent_ino = 2, name = "subdir2") -> fuse_reply_err(ENOENT) But then, fuse tries to perform a lookup on inode 3 anyway: lookup(parent_ino = 3, name = "subdir3") So why is fuse keeping inode 3 around, and why does it use it after the first lookup failed? Isn't that a bug? Or am I missing something? Thanks, -bryan |