Re: Monitoring changes in extended attributes?
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
Re: Monitoring changes in extended attributes?
On Monday 24 February 2003 07:25, Robert Watson wrote: 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. BeFS (in BeOS) had some interesting capabilities along these lines. It seems to me that the ability to monitor a mounted filesystem for inode changes would be a big plus. If you need to get from the inode number back to the filename or directory entry, you could either search or maintain an in-memory cache of the directory structure. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Monitoring changes in extended attributes?
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. --Kevin Fogleman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Monitoring changes in extended attributes?
Kevin Fogleman wrote: Is there an existing way to monitor the entire filesystem for changes to any file, particularly changes in extended attributes? On that note, I'm looking for an extended attribute I can set which will prevent monitoring for changes on a particular file... 8-) 8-). The answer is no, but you could add one using kevent; send patches. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
