Date: Mon, 24 Feb 2003 10:25:23 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Kevin Fogleman <krfogleman@comcast.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Monitoring changes in extended attributes? Message-ID: <Pine.NEB.3.96L.1030224102046.39246D-100000@fledge.watson.org> In-Reply-To: <3E4AEEBF.8020308@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030224102046.39246D-100000>