Watching Under The Hood Of Tiger's Spotlight

jaketheitguy writes "Over at KernelThread.com, Amit Singh has released a commandline app called FSLogger for looking under the hood of Tiger's Spotlight. You can watch all kinds of filesystem changes going on in realtime. The utility apparently intercepts and displays filesystem change data as it goes out to Spotlight from the kernel. It even tells you which app is making the changes. Looks like Apple has included some pretty powerful API's in Tiger and there may be some othre really interesting uses of this API as mentioned on the app's page. I for one would really like to be able to tell if somebody changed ANY files on my system without my knowledge. I think you can do that with Singh's program, but how do you make sure somebody cannot disable the program?"

Re:Tracking changes to the file system

[argent]

Yeh, when I heard about this I assumed that Apple would use kqueue and watch changes in the vnodes. It would require some extension to kqueue, because there's no "EVFILT_FS" or "EVFILT_VOP" filter that would monitor VOPs on more than a single file. But they needed to extend HFS+, too, so that's not really a big deal. You do have to be careful with this, because trying to monitor VOP_WRITE would be like drinking from a firehose... but you wouldn't actually need to track file content changes that closely for something like Spotlight that only needs to know that a file has changed recently. The key is that file content changes are reflected in the file modification time, so changes to the stat structure would be good enough if you delayed the actual examination of the file more than the granularity of time_t (one second), so by monitoring a few key VOPs you could get Spotlight working efficiently over any file system.

In fact, you could even just track inode changes and VOP_OPEN, VOP_MMAP, and VOP_CLOSE, and periodically peek at files that are open a long time to see if they're changed. The main thing is to be able to tell where to look without having to regularly traverse the whole file system.

Why they decided to use HFS+ instead of doing it at the vnode layer, I don't know. I can make some pretty good guesses, of course, because after all HFS+ is their baby and they really don't care much about supporting other file systems.

It's a shame. I really don't trust HFS+, and I wish they'd do more to support UFS transparently.