thanks for the quick response.
I have used dnotify on several rhel4 machines and it has always seemed fairly reliable. there are some weird things that happen file system wise.
For instance ... One instance I often use dnotify is to monitor files for uploads and then trigger a script to process the uploaded file. I have done this with video files that get uploaded and have it trigger off a script which calls ffmpeg/mencoder to convert the files over to flv.
With pureftp, the files come in as .pureftpupload-xxxxx where xxxx is some unique string. Once the upload completes, the file is renamed to match the client side.
Running dnotify with the -R option, to catch renames works, however, it also gets triggered if a duplicate file is getting uploaded ... so my guess is that when the original file gets deleted to make room for the new version, dnotify mistakes the deletion for a rename.
This is easy enough to check for in the script dnotify invokes, but it just takes a while to really figure out what the heck is happening
The 'auto heal' option I mention can be tricky - because redhat can throw out an update to sshd to fix a newly published exploit and the update is really needed before the exploit becomes viral and spreads throughout the hacker community. So, some cases, you would want to over ride an auto heal.
On a rpm based system, it might be possible to call rpm to verify the package the changed file belongs to...
something like :
rpm --verify `rpm -qf /usr/sbin/sshd` |grep /usr/sbin/sshd
if the RPM database indicates a change as well as the lfd MD5 check, replace the file with the known good replacement, otherwise accept the change and save the new version "in the vault".