On Wed, 12 Feb 2003, Kevin Fogleman wrote: > Is there an existing way to monitor the entire filesystem for changes to > any file, particularly changes in extended attributes? > > I'm looking to write a program that builds an index of all > user-accessable extended attributes for every file in the filesystem and > then updates that index in real time according to modifications to > existing files' attributes, creation of new files and deletion of files. > I've read over the documentation for kqueue, but some things were left > unclear. For example, it appears that kqueue needs a file descriptor > for each file that one would want to monitor, making any large-scale > file monitoring impractical. Is there any other way in FreeBSD to be > notified of file modifications in a way that would allow one to monitor > the whole file system or large portions of it? Also, I'm not very > knowledgable about file system conventions, so I'm wondering how one > would detect the creation of new files? I don't really need to know > whether a particular attribute changed, but rather just whether any of > them changed. > > BTW, I have posted this question earlier to freebsd-questions, but > nobody answered and, judging by the content of the other questions on > that list, I thought that my question would be more appropriate here.
Currently, you can monitor particular files for meta-data changes, which include extended attribute modifications, and you can monitor directories for changes, which might include the addition of a new name (and hence possibly a file). However, currently there's no way to monitor at the granularity of a file system for events such as "Some EA changed" or "A new file was allocated". I guess such primitives haven't generally been needed in the past, although I can certainly imagine scenarios where they might be used. Kqueue is the vehicle the two events I identified above can be monitored with, and it's certainly possible to imagine adding new event categories to monitor a file system for global events, assuming it's a local file system. However, then the question becomes "Once I know that a file has been added, how do I find it", which I would guess generally results in a recursive search, at which point I suspect you might as well just re-search the entire fs once in a while anyway. The functionality you're looking for sounds a bit more database-esque than in line with a traditional file store. FWIW, Apple has a searchfs() system call and vnode operation to permit more efficient meta-data searches on HFS+; this makes some sense for HFS+ because it has a notion of a centralized meta-data store, whereas ours is laid out pretty sparsely over the tree and works a bit differently. They don't support generalized meta-data extended attributes right now, though, although they do have a few specific attributes beyond the standard set. Well, we actually have local patches to add EA's to their UFS file system that would probably work on HFS+, but they aren't in the central Darwin tree. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message