On Sat, Jan 07, 2012 at 04:03:26PM +0100, Stef Bon wrote: > Futher, the FUSE fs knows it's own mountpoint. (ignore the submounts > on a FUSE fs here), it can filter out the watches which are set on the > fs. > This is not so hard right? What problems with "no way to tell at which > locations the damn thing happens to" you are pointing at?? Filesystem may be mounted at many places. The set of those locations depends on the process. It may change at any time. With no way for the filesystem to know about that (nor should it care, actually). See mount(2). Pay particular attention to MS_MOVE and MS_BIND flags (== --move and --bind in mount(8)). Moreover, it's not just maintaining the table of what is mounted where; different processes may bloody well have different sets of mounts. And even assuming we started sending notifications on *everything*, it still would not be enough - how is your FUSE server supposed to distinguish between * "add watch" notification sent * pathname argument of inotify_add_watch() resolved (down in inotify_find_inode()) * "mount --move" notification sent, mounted subtree moved and * "add watch" notification sent * "mount --move" notification sent, mounted subtree moved * pathname argument of inotify_add_watch() resolved (down in inotify_find_inode()) when the netlink traffic it sees is identical in both cases? And results are very much _not_ the same... IOW, what you are proposing is inherently racy. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
