On Sat, Mar 19, 2011 at 09:56:17AM +0100, Stef Bon wrote: > changes on the inode. When it recieves > some data(inotify events), it will push them forward to the inotify > watch on /home/a/mount/tmp. This is upto the developer > of the FUSE fs to implement this, but required to make this work is: > > a. when there is a notify watch set on a mounted FUSE fs, the VFS > should send the FUSE fs a signal a watch (with a mask) is set on a > particular inode. (and also when it's removed) > > b. the VFS should be able to listen to notify events coming from the FUSE fs. > > Actually the VFS is signalling to the FUSE fs that it wants to have an > inode to be up to date, and to be informed when changes occur. > > This example is about FUSE, but it also counts for a fs like cifs. > There the backend is a SMB share, and the SMB server has to support > inotify > to make this work. > > I hope you get the picture, Why, yes, we do. You do not. It is up to you to implement that; it is up to us to decide whether the result is acceptable for merge... FWIW, it's a bloody bad idea; inotify is not a generally usable mechanism. There is no way to make it work for non-local filesystems. You might be able to hack up something in FUSE protocol; getting FUSE *servers* to honour that is something entirely different, seeing that there are tons of them and these codebases are not in any way under control of kernel developers - or any single group, for that matter. Then there is NFS, where even the protocol side of things is not up to us, not to mention the server implementations. The same goes for CIFS/SMB, only there the odds of affecting the protocol (or one of the common servers - you know, the native Windows one) are even slimmer. Program relying on inotify is relying on specific configuration. Namely, the areas of the mount tree it's going to watch belonging to one of the filesystems where inotify works. Depending on what you are trying to do there might be saner (and more robust) ways to go - hard to tell without knowing what are you trying to achieve. -- 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
