Hi,
I have a FS filter driver that is monitoring read/writes to some
files. I would usually monitor the IRP_MJ_CREATE request and add the
file object to an internal list if I am interested in it. I then check
that list in the IRP_MJ_WRITE.
My problem is that the lazy writer (W2K, NTFS) seems to use a file
object that hasn’t come through the normal create path. The one that
was used in the original write seems to have been cleaned-up *and*
closed.
Is this normal behaviour, or am I missing something? I thought the cache
manager maintained a reference on the original file object and used that
to do the lazy writes, but that doesn’t seem to happen here.
If this is normal, is there a way to know when the lazy writer has
actually finished writing the file?
Thanks
Shaun
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
Shaun,
What you see is normal behavior. NTFS creates these file objects
via IoCreateStreamFileObject and IoCreateStreamFileObjectLite.
The work around is to maintain a table of FCBs instead of a table of
file objects. Each FCB record in your table in turn maintains a list of
file objects. The list of file objects serves as sort of a reference count
for the fcb record for the file. In your dispatch routines, you look up the
FCB of the file object referenced by the IO in you table. If the file
object is not in that FCBs list, you add it to the list. You remove file
objects from the list during close. At some point, you will recieve a close
that removes the last file object from the FCBs list. At this time, if you
have filtered the appropriate dispatch routines, you can be sure that all
extant file objects for your fcb record have been closed.
Note, this scheme only applies if you are tracking state per file,
and not per open instance of the file (although you could adapt it to work
with the latter requirement).
-Joel
-----Original Message-----
From: Shaun [mailto:xxxxx@sdlabs.demon.co.uk]
Sent: Friday, June 22, 2001 5:30 AM
To: File Systems Developers
Subject: [ntfsd] Lazy writes
Hi,
I have a FS filter driver that is monitoring read/writes to some
files. I would usually monitor the IRP_MJ_CREATE request and add the
file object to an internal list if I am interested in it. I then check
that list in the IRP_MJ_WRITE.
My problem is that the lazy writer (W2K, NTFS) seems to use a file
object that hasn’t come through the normal create path. The one that
was used in the original write seems to have been cleaned-up *and*
closed.
Is this normal behaviour, or am I missing something? I thought the cache
manager maintained a reference on the original file object and used that
to do the lazy writes, but that doesn’t seem to happen here.
If this is normal, is there a way to know when the lazy writer has
actually finished writing the file?
Thanks
Shaun
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.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
Okay. so we use the FCB as a common link between all file objects
associated with a file. When we receive close requests we remove the
file objects from the FCB’s list. When the FCB’s list is empty we can
free it (the FCB). But what I see so far is the following
// normal file I/O stuff
CREATE <- New FCB, FileObjects = 1
– some access
CLEANUP
CLOSE <- Remove FileObject, FileObjects=0 -> remove FCB
// from lazy writer using NTFS’s stream FIleObject
WRITE <- No FCB, add new, FIleObjects=1
To make this work I need to ensure that I see a CLOSE for the stream
file object that NTFS created. Are you saying that at some point
(probably much latter), I *will* see the CLOSE for the stream object?
Shaun
Smith, Joel wrote:
>
> Shaun,
> What you see is normal behavior. NTFS creates these file
> objects via IoCreateStreamFileObject and
> IoCreateStreamFileObjectLite.
>
> The work around is to maintain a table of FCBs instead of a
> table of file objects. Each FCB record in your table in turn
> maintains a list of file objects. The list of file objects serves
> as sort of a reference count for the fcb record for the file. In
> your dispatch routines, you look up the FCB of the file object
> referenced by the IO in you table. If the file object is not in
> that FCBs list, you add it to the list. You remove file objects
> from the list during close. At some point, you will recieve a
> close that removes the last file object from the FCBs list. At
> this time, if you have filtered the appropriate dispatch routines,
> you can be sure that all extant file objects for your fcb record
> have been closed.
>
> Note, this scheme only applies if you are tracking state per
> file, and not per open instance of the file (although you could
> adapt it to work with the latter requirement).
>
> -Joel
>
> -----Original Message-----
> From: Shaun [mailto:xxxxx@sdlabs.demon.co.uk]
> Sent: Friday, June 22, 2001 5:30 AM
> To: File Systems Developers
> Subject: [ntfsd] Lazy writes
>
>
> Hi,
>
> I have a FS filter driver that is monitoring read/writes to some
> files. I would usually monitor the IRP_MJ_CREATE request and add
> the
> file object to an internal list if I am interested in it. I then
> check
> that list in the IRP_MJ_WRITE.
>
> My problem is that the lazy writer (W2K, NTFS) seems to use a file
> object that hasn’t come through the normal create path. The one
> that
> was used in the original write seems to have been cleaned-up and
> closed.
>
> Is this normal behaviour, or am I missing something? I thought the
> cache
> manager maintained a reference on the original file object and used
> that
> to do the lazy writes, but that doesn’t seem to happen here.
>
> If this is normal, is there a way to know when the lazy writer has
> actually finished writing the file?
>
> Thanks
> Shaun
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
> To unsubscribe send a blank email to
> leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@sdlabs.demon.co.uk
> 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
in your close, call
CcGetFileObjectFromSectionPtrs(PtrFileObject->SectionObjectPointer) with the
current file obj to get the file obj ptr used by the cache manager for the
write.
Ho Mun Chuen
@@ “Not everything that counts can be counted;
<” )~ and not everything that can be counted counts"
//\ … Albert Einstein
----- Original Message -----
From: “Shaun”
To: “File Systems Developers”
Sent: Friday, June 22, 2001 10:29 PM
Subject: [ntfsd] RE: Lazy writes
Okay. so we use the FCB as a common link between all file objects
associated with a file. When we receive close requests we remove the
file objects from the FCB’s list. When the FCB’s list is empty we can
free it (the FCB). But what I see so far is the following
// normal file I/O stuff
CREATE <- New FCB, FileObjects = 1
– some access
CLEANUP
CLOSE <- Remove FileObject, FileObjects=0 -> remove FCB
// from lazy writer using NTFS’s stream FIleObject
WRITE <- No FCB, add new, FIleObjects=1
To make this work I need to ensure that I see a CLOSE for the stream
file object that NTFS created. Are you saying that at some point
(probably much latter), I will see the CLOSE for the stream object?
Shaun
Smith, Joel wrote:
>
> Shaun,
> What you see is normal behavior. NTFS creates these file
> objects via IoCreateStreamFileObject and
> IoCreateStreamFileObjectLite.
>
> The work around is to maintain a table of FCBs instead of a
> table of file objects. Each FCB record in your table in turn
> maintains a list of file objects. The list of file objects serves
> as sort of a reference count for the fcb record for the file. In
> your dispatch routines, you look up the FCB of the file object
> referenced by the IO in you table. If the file object is not in
> that FCBs list, you add it to the list. You remove file objects
> from the list during close. At some point, you will recieve a
> close that removes the last file object from the FCBs list. At
> this time, if you have filtered the appropriate dispatch routines,
> you can be sure that all extant file objects for your fcb record
> have been closed.
>
> Note, this scheme only applies if you are tracking state per
> file, and not per open instance of the file (although you could
> adapt it to work with the latter requirement).
>
> -Joel
>
> -----Original Message-----
> From: Shaun [mailto:xxxxx@sdlabs.demon.co.uk]
> Sent: Friday, June 22, 2001 5:30 AM
> To: File Systems Developers
> Subject: [ntfsd] Lazy writes
>
>
> Hi,
>
> I have a FS filter driver that is monitoring read/writes to some
> files. I would usually monitor the IRP_MJ_CREATE request and add
> the
> file object to an internal list if I am interested in it. I then
> check
> that list in the IRP_MJ_WRITE.
>
> My problem is that the lazy writer (W2K, NTFS) seems to use a file
> object that hasn’t come through the normal create path. The one
> that
> was used in the original write seems to have been cleaned-up and
> closed.
>
> Is this normal behaviour, or am I missing something? I thought the
> cache
> manager maintained a reference on the original file object and used
> that
> to do the lazy writes, but that doesn’t seem to happen here.
>
> If this is normal, is there a way to know when the lazy writer has
> actually finished writing the file?
>
> Thanks
> Shaun
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
> To unsubscribe send a blank email to
> leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@sdlabs.demon.co.uk
> To unsubscribe send a blank email to
> leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@computer.org
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