I need the most generic UNIX method to detect file system events
(create, update and delete).
Possible solutions may include:
1) a reference to source code that does not poll the system but has a
way to catch signals or interrupts.
2) a reference to a book that explains the details of intercepting an interrupt.
3) An example of how to hook device drivers.
Or, just a nudge in the right direction - maybe I'm barking up the wrong tree???
Thanks,
-Jmt |
Request for Question Clarification by
maniac-ga
on
17 Mar 2005 17:28 PST
Hello Jmt,
The most "generic" method to do what you ask would require polling the
file system. Sorry - but there are enough inconsistent Linux / Unix
implementations out there to make any other method non portable. I
could point you to some pages that refer to polling in popular file
system browsers (e.g., KDE Konqueror) if you are interested. It is
also pretty simple to script a simple polling method using something
like "df" (to track file system used/free sizes) to trigger an update;
if that is OK, please indicate so.
You MAY be able to hook into the OS in some way, but that hook will
vary by OS version. For example, in Linux, you could use the SELinux
framework to trap all file system (as well as several other)
operations and forward the relevant information to a daemon written by
yourself. If that kind of approach is acceptable, I can certainly
point you in the right direction.
Indicating the Unix OS versions you are interested in would also help
the search for a solution.
--Maniac
?
|
Clarification of Question by
jmt-ga
on
21 Mar 2005 10:23 PST
Maniac,
What about sy_call()? It looks like it could be used on most UNIX
systems. The possiblily that I would have to modify the call for
specific systems is ok. Have you used this? Can it be used to build
a file monitor that doesn't involve polling?
Thanks,
-Jmt
|
Request for Question Clarification by
philip_lynx-ga
on
21 Mar 2005 12:07 PST
As has been stated above, there are no 'generic' unix methods to
detect file system events. If you can however narrow down the OS in
question, maybe we can assist you better.
Plus, are you looking at entirely user-space approaches to this? Would
you be willing to consider kernel modifications (as your mentioning
of sy_table seems to imply)?
|
Clarification of Question by
jmt-ga
on
21 Mar 2005 13:06 PST
Narrowing down the OS would defeat a large part of our purpose.
>> willing to consider kernel modifications
Absolutely. Once I know how to modify the kernel for one system,
I can probably find how to do the same on other systems much faster.
We don't want to resort to polling, but we do plan to have a simple
catalog system in place for systems that don't support the lower level
approach.
We thought about intercepting an IRQ, but that might not work because
some operations don't necessarily involve a hardware interrupt.
Thanks,
-Jmt
|
Request for Question Clarification by
philip_lynx-ga
on
21 Mar 2005 13:51 PST
At this point, I see some possible solutions:
1) use existing and specific hooks. The most common approach is fam
(see http://oss.sgi.com/projects/fam/ for more info. fam is available
for e.g. Linux and Irix -- for Solaris the way to go would be
2) use auditing features (BSM monitoring or dtrace for Solaris) to
capture file modification events.
3) Intercept system calls. (This becomes challenging in the light of
mmap() and relatives)
4) Add your own hooks on the VFS or actual FS level.
5) Mirror the FS in question through NFS or PCFS, and intercept
operations in the FS server.
6) ...
As you can see, the area gets pretty broad.
Please advise how I can best help you further?
|
Clarification of Question by
jmt-ga
on
21 Mar 2005 14:39 PST
I was looking for a more fundamental approach than fam, but it looks
like it's gonna be either /dev/poll or fam.
You've answered my question sufficiently.
Thanks for the help,
-Jmt
|
Request for Question Clarification by
philip_lynx-ga
on
21 Mar 2005 16:43 PST
My pleasure. If I had full liberties, and would not have to worry
about protability, I'd personally go for the FS layer, and intercept
when ctimes and mtimes of an inode are updated. That way you would
catch all the different write paths, by instrumenting hopefully just a
few places.
If you feel my fragmentary answer has been enough for your needs,
maybe you want to reduce the list price, and have me claim that
reduced price?
|
Clarification of Question by
jmt-ga
on
22 Mar 2005 09:58 PST
I value your time. I am happy to pay the list price. The amount of
time that has gone into this dialog is worth more than $25, so I was
affraid you would ask me to raise the price. I haven't used this
forum enough to know how that negotiation should work, so let me know.
I could just a little more help to understand your comments. I don't
really have that much UNIX experience, so a lot of this is new to me.
I'm trying to use /dev/poll on Solaris hoping that I can get it to
monitor an entire directory. I put the fd for the directory into the
dvpoll_t structure and use ioctl(fd,DP_POLL..., but I'm having a tough
time getting that setup right. Does this sound like it could work for
Solaris?
If I hook the fs, what do I use to setup the inode to monitor a directory?
|
