Messages in this thread | | | Date | Tue, 11 May 2004 13:46:47 +0100 | From | viro@parcelfa ... | Subject | Re: [RFC/PATCH] inotify -- a dnotify replacement |
| |
On Tue, May 11, 2004 at 08:20:01AM -0400, John McCutchan wrote:
> Inotify will support watching a hierarchy. The reason it was not > implemented yet is because the one app that I really care about is > nautilus and the maintainer of it says he doesn't care.
How are you going to implement that?
> The big feature that inotify is trying to provide is not having to keep > a file open (So that unmounting is not affected). I asked for some > guidance from people more familiar with the kernel so that I can > implement this feature, it requires changes made to the inode cache, and > how unmounting is done.
Bzzert. First of all, on quite a few filesystems inumbers are stable only when object is pinned down. What's more, if it's not pinned down you've got nothing even remotely resembling a reliable way to tell if two events had happened to the same object - inumbers can be reused.
Besides, your "doesn't pin down" is racy as hell - not to mention the way you manage the lists, pretty much every function is an exploitable hole. Hell, just take a look at your "find inode" stuff - you grab superblock, find an inode by inumber (great idea, that - especially since on a bunch of filesystems it will get you BUG() or equivalent) then drop refernce to superblock (at which point it can be destroyed by umount()) _and_ do iput() (which will do lovely, lovely things if that umount did happen). Moreover, you return a pointer to inode, even though there's nothing to hold it alive anymore. And dereference that pointer later on, not caring if it had been freed/reused/whatever.
Overall: hopeless crap. And that's a direct result of your main feature - it's really broken by design. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |