Re: Using KAuth for Monitoring File Operations
Re: Using KAuth for Monitoring File Operations
- Subject: Re: Using KAuth for Monitoring File Operations
- From: Michael Smith <email@hidden>
- Date: Fri, 15 Jun 2007 09:45:14 -0700
On Jun 15, 2007, at 6:59 AM, Amanda Walker wrote:
On Jun 15, 2007, at 4:05 AM, Yogesh Kulkarni wrote:
The application i am currently working on needs to do simple Copy-
On-Write mechanism by which i will be able to take the backup of
those files
which are going to be modified. So, i am more interested in
getting the event before the read/write operation on particular
file or before the data gets
modified for the file. But currently KAuth is giving event to my
user space application after the file data gets modified because
of this i am not
able to get the previous state of that file for achieving Copy-On-
Write mechanism.
My main aim is to keep the previous state of the file to some
other location before modified data gets written to that file.
This is not going to be possible with Kauth, since a Kauth module
gets notified after the I/O operation is already underway. You can
deny the operation, but you can't interpose user space processing
in between seeing the request and either denying it or letting it
proceed.
Hang a sec there, Amanda.
Firstly Yogesh, you should check with your co-workers, or perhaps
whoever had this project last; I think we were last talking about
this late in April with Shailesh Parulekar, and I'm sure I've
answered these questions at least once before that.
That being said, let's try to set you on a right path.
What do you define as "modified"?
In the most simplistic case, you can hook the VNODE scope, and any
time an operation goes past that looks like it might be requesting
the right to alter a file, consider the file to be potentially about
to be modified.
You have a couple of problems here;
- You have no idea whether the file will actually be modified, or
whether permission will even be granted to modify the file, just
because you have seen a request to be granted permission to modify go
past.
- The file may already be open, meaning that if you back it up and
overwrite a previous version, you may end up saving a version with
partial changes.
If your product's aim is to have a complete backup copy of
everything, then you are better off waiting in the FILEOP scope for
last-close notifications with the modified flag set. This gives you
both the indication that the file is not being modified, and an
indication that it previously has been.
All of this leaves the issue of metadata changes completely up in the
air.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden