Hey Chris,
see some comments from my point of view inline.
Chris Rijk schrieb:
Here are a some of the file event types considered.
FILE_OPEN File opened.
FILE_CLOSE File closed.
FILE_WRITE File was written to.
FILE_READ File was read.
FILE_ATTRIB_CHANGE File attributes changed
FILE_CREATE File/Directory was created.
FILE_REMOVE/UNLINK File/Directory was removed/deleted.
FILE_RENAME_TO/FROM File was renamed to/from.
How about file locking/unlocking?
Could be realized as FILE_ATTRIB_CHANGE notification.
If a file was resized (truncated), how would that be represented?
Could be realized as FILE_WRITE event.
It might also be an idea to be able to differentiate between file-writing and file-appending.
might be. But I think it is task of the application programmer
to react to the event FILE_WRITE if he is interested in differentiating
between these facts.
What would happen if one file was renamed over another - would you get one event
or two (one for rename, one for old file effectively being deleted)?
This is an interesting question that should be answered automatically
when you take into account that file events are "bound" to particular
files (or a list of them or a directory). And this is the answer. If you
have "subscribed" to get events for the old file, you get FILE_REMOVE;
if you are "observing" the old file and the e.g. directory, you get two.
As a related concept, does anyone know how easy or practical it would be to
use ZFS's copy-on-write update mecanism to be able to read a "log" (effectively)
of recent changes to a file-system? I'm thinking of an API where you start by
passing
a start date/time, and then can iterate through each change in sequence.
Obviously,
there would be no gurantees on the scope (in terms of date range) of such data.
Shouldn't be a problem as file events use event ports and these are
independent of the underlying filesystem (UFS, ZFS, NFS?).
Best regards,
Michael
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
