Oh dear. If it has the same silly open-the-whole-tree problem before you know you have all change events, it's *not* suitable for non-disk bashing indexers.
And it's not suitable for non-disk bashing virus checkers / tripwire-like programs either.
Disk bashing is what happens each time you restart or remount a filesystem. Just to traverse the directory tree to set inotify events on it.
Last time I discussed this with Tracker folks, their answer was "most users don't have a lot of files, you are unusual as only developers typically have lots of files and a rich directory tree".
Thanks, guys. What happened to doing things right?
Occasionally a thoughtful response emerges: "but you can't notify all the parent directories if a hard-linked file is modified". A natural gut instinct, but mistaken.
inotify already determines parent directories of all files, including linked ones, in a path-based manner: when you change a file, it follows the path used to access the file to notify listeners on the containing directory. Linked files can be monitored accurately by either watching the inode itself, or watching all known parent directories, which you can verify from the link count and bind-mount points - a userspace problem.
So do the obvious thing, and notify listeners on all containing directories up the whole path used to access the file. (And provide an IN_ATTRIB event when the link count is incremented by linking - seen by watchers on the source path - currently that omission makes directory inotify unsuitable for verifying lack of file changes even with deep tree traversal at the moment).
Then userspace has enough to watch whole trees with the same fidelity as it can now, but much more efficiently - no massive traversal required. No disk bashing. It'd be nice to catch up with Windows 2000 in this department.