Re: Questions about Fswatcher for Linux kernel 2.6.x

[Enrico Sersale]

On 2006-03-31 04:34:21 +0300 Charles Philip Chan <cpchan@sympatico.ca> wrote:

> Hello Enrico:
>
> I want to try test the new fswatcher for Linux kernel 2.6.x, however I
> have a few questions:

First I want to say that GWorkspace doesn't need these system-specific versions 
of fswatcher; they are simply faster but don't add anything new from the 
GWorkspace point of view.
The new features are useful only for mdextractor, a new daemon that extracts 
and keep updated words contents and other metadata attributes from your files 
(something like Apple Spotlight, to understand).
If you want to try it (even if this is only work in progress), you must install 
the gmds and mdextractor daemons that are in Tools/gmds and the 
SystemPreferences module that is in Preferences/Indexing.
For the moment there is not a client because the client will substitute the 
actual Finder and I can't do this if I don't find a reliable solution for linux 
2.6.x.

> (1) What rules should I put into /etc/audit.rules for GWorkspace.app?

I have:

-a exit,always -S open
-a exit,always -S creat
-a exit,always -S mkdir
-a exit,always -S rmdir
-a exit,always -S unlink
-a exit,always -S rename

> (2) The log files generated by auditd is only readable by root- I
>     can't seem to find an option for log file permissions. I manage to
>     get it working for a while after changing the permission of the
>     log file, however fswatcher dies when the log gets rotated.

For the moment you should run it suid root.

> Just out of curiously, why was auditd chosen instead of fam
>
>      http://oss.sgi.com/projects/fam/index.html
>
> or use d/inotify directly? The reason why I am asking this is because:
>
> (1) Fam is well tested and included with all Linux distros and used by
>     many software for a number of years while auditd is not.
>
> (2) You are not kidding in one of your earlier posts- auditd slowed my
>     system to a crawl.

Because fam and inotify need a list of directories to watch and this is exactly 
what fswatcher already does since years with a simplier and totally portable 
mechanism.
What I need is something that reports *all* the changes that happen in the 
filesystem.
And this is not necessairly a resource-intensive process; it is the linux 
kernel and/or the auditd daemon that don't work reliably; if you try the 
fswatcher version for darwin-8 (that reads from /dev/fsevents as spotlight 
does), you will see that your system is not slowed at all.

> Thanks,
> Charles