Re: [Tracker] Linux kernel watchless file notification

[Jamie McCracken <jamiemcc blueyonder co uk>]

On Mon, 2008-04-21 at 11:13 +1000, Ian Howson wrote:
> > well to do the kernel thingy we need a generic kernel notification
> > thingy that only root can read
>
> Would the intent there be to have a 'master' Tracker daemon that is 
> system-wide and which provides the required security semantics to individual 
> user searches?

no a root based file watcher with an sqlite db to store history for last
month or two. It would allow clients to recieve file events providing
they have permissions + allow apps to request all file events from a
certain time (via sqlite db)


> > then we need to modify libc to make use of said notification thingy as
> > kernel team will not allow resolution of file descriptors to file paths
> > within the kernel
>
> Why does this have to go through libc? I would have thought this would be kept 
> out of libc precisely because it is a kernel-specific API. There will need to 
> be a way to resolve inodes/fd's to paths, certainly, but this is a solvable 
> problem.



Well i would have thought keeping a b-tree/hashtable of fd to file path
+ name would suffice - it would remove the need to resolve filenames in
kernel at expense of a bit of memory. When files are closed they are
removed from b-tree/hash




> My initial ideas were to use either the same mechanism as inotify but with 
> better semantics for our purposes, or port across something like BSD kevents. 

there is already a patch for inotify for this but got rejected by kernel
team due to above


see my blog entry and comments for more info -
http://jamiemcc.livejournal.com/10814.html?nc=10



> Is anyone actively working on something to solve this general problem, or 
> should I just go ahead and hack something together? :-)

please do - if you can get your stuff in the kernel then great!

Im quite happy to do the userspace daemon to monoitor filesystem as i
stated above

jamie