At first look, this seems very similar to FAM (which even supported NFSv3, using custom notifications over SunRPC).
Later I remember GNOME replaced it with Gamin and finally with local-only inotify inside glib/gvfs. It might be useful to revive it, both inotify and fanotify have problems. But I guess security would be a problem (how to determine which users may receive which events). -- Mantas Mikulėnas On Jul 28, 2015 18:46, "Stef Bon" <stef...@gmail.com> wrote: > Hi all, > > for some time I have been looking at the issue why fsnotify does not work > with network filesystems and FUSE (with a shared backend). > > I've found out that changes initiated on the localhost, on the filesystem > are supported by the fs change subsystems on Linux, and events initiated at > the backend (from another host with network fs) are not detected. This is > because the filesystem are not "aware" a watch has been set on an inode, > and thus cannot act on it. > (if they act if they are aware is another question). > > I've tried to tackle this in the kernel. I've made this working with a > FUSE: > - when a watch is set on a FUSE fs, a message is forwarded to the > userspace daemon containing the inode and the mask. I had to add a opcode > FUSE_FSNOTIFY. > - the fuse fs has to react in it, by setting a watch on the backend. I > wrote a simple overlay fs, and setting a watch on the backend is simple > - I had to add some calls to the fuse library to "push" changes to the VFS > where there is no direct related call from the VFS. (files are added and/or > files are changed) > - the FUSE kernel module in VFS has to trigger fsnotify call when events > are pushed to the VFS by the userspace daemon. > > This worked but is I think not the best way to deal with it. > > My suggestion it to write a fs notify change service which does all the > watching for clients, like there are already services for desktops right > now. > > This service should also work with a console app like mc, but also with > desktop environments like Gnome and KDE. > > It should also be able to "forward" a watch to a filesystem like FUSE and > cifs and nfs, so that they "know" a watch has been set. > They can act then on it, by forwarding the watch to the backend. SMB does > upport this, NFS4 also, and you can make FUSE also support it(depending the > protocol). > When the fs receives an event, it can send it back to the fs notify change > service, which informs the client(s). This way the filesystem also stays up > to date. > > To forward a watch and to read to incoming fsevents, a > socket/filedescriptor is required. A FUSE fs can easily connect to it at > startup, the in kernel filesystems need some extra. Via mountoptions parse > the fd to the kernel? > > Is this something what can be added to systemd? Please let me know what > you think of it. > > Stef > > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel