John Levon wrote:
On Wed, May 03, 2006 at 02:44:01PM -0700, Prakash Sangappa wrote:
FILE_CREATE File/Directory was created.
I think GNOME and others want to be able to watch an entire directory tree. It
sounds like the proposal is that you can only watch a particular path
"/etc/non_existent_file" for FILE_CREATE? If not, can you expand on this? What
do I have to pass in as the 'object' to port_associate() with these events?
Parent directory? If so, is it recursive?
If you where to watch for events on an entire directory tree, what types
of events that
would be? How would this be useful?
Yes, it is to watch a file or a directory. The events which are
relevant will be delivered.
So the case where you want to watch for a file being created
"/etc/non_existent_file"
can be to just a watch on the directory "/etc". The FILE_CREATE event
would mean
that a file or a directory was created under "/etc". Once the
application gets this event,
it can go and check if the file got created.
We could make it watch for a particular file being created like
"/etc/non_existent".
But once this event is delivered, the application will have to again
check to see if this
file exists as it can get deleted by the time the event it received.
Clearly this is
going to be racy.
Therefore the event types can be simplified. Instead of having events
for OPEN, READ, WRITE, CREATE we could just have
ACCESS & MODIFY. Then you just watch to see if a file or
a directory is accessed or modified and then perform the necessary
checks and take action.
How does it interact with unmounting the underlying filesystem?
It will hold a reference to the 'vnode' of the file/directory in the
kernel, while we have
the file events monitor on it. If the file system gets unmounted, it
will de-register the
monitor and send an exception event saying the filesystem got unmounted.
These exception events need to be defined.
You say that list is "some of the event types" planned. Presumably there are
others?
This was an initial set to get the discussion going. The idea is to keep
it simpler and
limit them to a basic set of events that will server the purpose.
Rgds,
-Prakash.
regards
john
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
