Date: Wed, 11 Mar 2015 16:43:41 -0700 From: Julian Elischer <julian@freebsd.org> To: "O'Connor, Daniel" <darius@dons.net.au>, Kim Shrier <kim@westryn.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: file system change notifications Message-ID: <5500D32D.30703@freebsd.org> In-Reply-To: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> References: <C4BD68D4-0570-4731-AFA2-CDD4DD5490E5@westryn.net> <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/11/15 3:46 PM, O'Connor, Daniel wrote: >> On 12 Mar 2015, at 05:31, Kim Shrier <kim@westryn.net> wrote: >> I have a project where I need to notice changes to files in a large directory tree. >> I noticed that there was a project in GSOC 2010 to implement such a feature. >> >> https://wiki.freebsd.org/SOC2010IlyaPutsikau >> >> It appears that it was never completed. Is it desirable to have this project >> completed and added into FreeBSD. Or, is there another way to get file >> system change notifications? > The 'standard' way is kqueue + masses of file descriptors. > > I am looking at using auditpipe(4) since you can register to be notified for all file modifications and you get a path. > > I wrote some test code at https://gist.github.com/DanielO/e36de242e79fed3fe4f7 > > Ideally we could add an inotify() syscall although I think that is still suboptimal since you need to add a watch per directory so it can be relatively expensive to setup. That said working out what to do in the face of links and so on is tricky.. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > I think there are a few things that could lead to a relatively efficient way of doing this.. if you wanted to watch all the files in a subtree, you should be able to put an annotation in the vnode of base of that subtree, that would indicate that fact. Then you could modify lookup/namei so that any vnode returned from that lookup, that went past that notification would also get the annotation. Obviously if the lookup was relative then the anotation initial state would be inherrited from the start point (CWD?). you woudl have to be ready to remove annotations on the way down (..) but that seems doable. The annotations would refer to a specific kevent item and child processes inherritance rules would work as per normal. each vnode coudl end up being watched by many kevents so therw woudl have ot be some many to many mapping.. a cancelled kevent woudl need ot be able to remove all related anotations, and a touched file woudl need to be able to make several notifications. The "hole" would be that vnodes that already exist within the watched zone would not have the anotation, so you'd have to do root-wards searches to add them when the zone was added (or just live with that). If you search downwards towards root you have to add any annotation you find on any ancestor vnode. but all file activities have to start with an opened vnode somewhere.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5500D32D.30703>