Tony:
That’s right. I reference FO for the solely purpose of keeping FsContext as
an identifier that would allow the simplest and quickest way of detecting
that this particular file has been opened.
Although this idea looks attractive, I’m afraid it’s not going to work for
me. Or, at least, I’m not sure what’s going to happen if a folder in the
path to this file gets renamed. My guess is that this file will be treated
as “another” one so next time it is opened a new FsContext will be
generated.
Best regards,
Vladimir
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Sunday, December 02, 2001 9:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: ObReferenceObject or keeping FO alive…
Vladimir,
For the purposes you describe, I believe you’d be OK. The problem that Max
mentioned is that you are only allowed to perform certain operations between
cleanup and close using that file object. If you are tracking *state* and
not using the file object for I/O, you shouldn’t observe any problems.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Sunday, December 02, 2001 12:39 PM
To: File Systems Developers
Subject: [ntfsd] Re: ObReferenceObject or keeping FO alive…
Can you provide more details on that?
Regards,
Vladimir
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Sunday, December 02, 2001 9:39 AM
To: File Systems Developers
Subject: [ntfsd] Re: ObReferenceObject or keeping FO alive…
IIRC it can be problematic - to call ObReference from inside the CLEANUP
path.
Tony Mason once told about possible problems there.
Max
----- Original Message -----
From: Chtchetkine, Vladimir mailto:xxxxx
To: File Systems mailto:xxxxx Developers
Sent: Sunday, December 02, 2001 8:21 PM
Subject: [ntfsd] ObReferenceObject or keeping FO alive…
Hi guys!
In my filter driver I need to implement some file modification tracking in
which I need to create a copy of the modified file after last file handle
has been closed and during some period of time file has not been accessed.
Thinking about the details of implementation I came up with an idea that
most efficient way to handle this would be to “hold on” to the FileObject
(and thus its FsContext) after last handle’s clean up. So, basically, my
model would be:
In CLEANUP routine that is recognized as “last file handle closed” I would
ObReferenceObject(FileObject), save FileObject in a “copy pending” list, let
the Cleanup go and for each newly opened file I would get its FsContext and
look up for the same FsContext in my “copy pending” list. If found, I will
ObDereferenceObject for my “copy pending” FO.
How does this sound? Are there anything that I’m missing that would make
this model or the system not working?
TIA,
Vladimir
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@Starbase.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@Starbase.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</mailto:xxxxx></mailto:xxxxx>