Our file system filter driver traces a file from opening to closing by using our FCB.
It creates FCB at the first IRP_MJ_CREATE, and then delete it at the last IRP_MJ_CLOSE.
It identifies each file by the value of FCB’s “FileObject->FsContext” which the file system creates.
There’s a problem here.
In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after the last IRP_MJ_CLOSE.
This IRP_MJ_WRITE does not pass the filter.
We’d like to manage FCB synchronizing with the one in the file system.
Does anyone know when the FCB should be deleted on the filter driver?
FsRtlInsertPerStreamContext?
wrote in message news:xxxxx@ntfsd…
> Our file system filter driver traces a file from opening to closing by
> using our FCB.
> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the last
> IRP_MJ_CLOSE.
> It identifies each file by the value of FCB’s “FileObject->FsContext”
> which the file system creates.
>
> There’s a problem here.
> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after
> the last IRP_MJ_CLOSE.
> This IRP_MJ_WRITE does not pass the filter.
>
> We’d like to manage FCB synchronizing with the one in the file system.
> Does anyone know when the FCB should be deleted on the filter driver?
>
Sounds like you need to read the article at OSROnline on tracking
context information. If you are a legacy filesystem filter driver, which
it sounds like you are since you are referring to IRP_MJ_xxx vs pre/post
callbacks, then for particular cases you need to check the state of the
Section Object pointers to determine if the IRP_MJ_CLOSE you think is
the ‘last’ one is really the last one.
I suspect you are hitting the case where a stream fileobject is being
created to initialize caching, per NTFS semantics, and thus your
reference counting approach, if using standard techniques, is off.
Go to OSROnline and look in the IFS FAQ for the reference counting
article. This will explain what you are seeing.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
xxxxx@sciencepark.co.jp wrote:
Our file system filter driver traces a file from opening to closing by using our FCB.
It creates FCB at the first IRP_MJ_CREATE, and then delete it at the last IRP_MJ_CLOSE.
It identifies each file by the value of FCB’s “FileObject->FsContext” which the file system creates.
There’s a problem here.
In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after the last IRP_MJ_CLOSE.
This IRP_MJ_WRITE does not pass the filter.
We’d like to manage FCB synchronizing with the one in the file system.
Does anyone know when the FCB should be deleted on the filter driver?
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after the
last IRP_MJ_CLOSE.
After CLOSE, the file object is destroyed immediately. Maybe you mean CLEANUP?
or the same memory address was reused by another file object? such reuses are
often.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hello Peter
I assume you have not experienced the case where a driver below uses
IoCreateFileSpecifyDeiceObjectHint so you do not see the file object for
that create, ever, and yet cacheing is established against that file object,
and yet you see the xCB because you see another file object because
a.n.other has opned the file, perhaps before
IoCreateFileSpecifyDeviceObjectHint was called. In this case refrence count
plus SectionObjectPointers approach cannot discard the xCB related state,
ever. Hence you see my first response since no other solution is possible
for lgeacy filter in presence of IoCreateFileSpecifyDeviceObjectHint.
Best Wishes
Lyndon
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Sounds like you need to read the article at OSROnline on tracking context
> information. If you are a legacy filesystem filter driver, which it sounds
> like you are since you are referring to IRP_MJ_xxx vs pre/post callbacks,
> then for particular cases you need to check the state of the Section
> Object pointers to determine if the IRP_MJ_CLOSE you think is the ‘last’
> one is really the last one.
>
> I suspect you are hitting the case where a stream fileobject is being
> created to initialize caching, per NTFS semantics, and thus your reference
> counting approach, if using standard techniques, is off.
>
> Go to OSROnline and look in the IFS FAQ for the reference counting
> article. This will explain what you are seeing.
>
> Pete
>
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> xxxxx@sciencepark.co.jp wrote:
>> Our file system filter driver traces a file from opening to closing by
>> using our FCB.
>> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the last
>> IRP_MJ_CLOSE.
>> It identifies each file by the value of FCB’s “FileObject->FsContext”
>> which the file system creates.
>>
>> There’s a problem here.
>> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after
>> the last IRP_MJ_CLOSE.
>> This IRP_MJ_WRITE does not pass the filter.
>>
>> We’d like to manage FCB synchronizing with the one in the file system.
>> Does anyone know when the FCB should be deleted on the filter driver? —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
If caching has been established on any FO pointing to the file then
inspecting the pointers within the SOP will tell you that there is
another reference and hence you should not tear down your control
structure. Using this, in combination with reference counting, will
handle this situation.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
Lyndon J Clarke wrote:
Hello Peter
I assume you have not experienced the case where a driver below uses
IoCreateFileSpecifyDeiceObjectHint so you do not see the file object for
that create, ever, and yet cacheing is established against that file object,
and yet you see the xCB because you see another file object because
a.n.other has opned the file, perhaps before
IoCreateFileSpecifyDeviceObjectHint was called. In this case refrence count
plus SectionObjectPointers approach cannot discard the xCB related state,
ever. Hence you see my first response since no other solution is possible
for lgeacy filter in presence of IoCreateFileSpecifyDeviceObjectHint.
Best Wishes
Lyndon
“Peter Scott” wrote in message
> news:xxxxx@ntfsd…
>> Sounds like you need to read the article at OSROnline on tracking context
>> information. If you are a legacy filesystem filter driver, which it sounds
>> like you are since you are referring to IRP_MJ_xxx vs pre/post callbacks,
>> then for particular cases you need to check the state of the Section
>> Object pointers to determine if the IRP_MJ_CLOSE you think is the ‘last’
>> one is really the last one.
>>
>> I suspect you are hitting the case where a stream fileobject is being
>> created to initialize caching, per NTFS semantics, and thus your reference
>> counting approach, if using standard techniques, is off.
>>
>> Go to OSROnline and look in the IFS FAQ for the reference counting
>> article. This will explain what you are seeing.
>>
>> Pete
>>
>> Kernel Drivers
>> Windows File System and Device Driver Consulting
>> www.KernelDrivers.com
>> (303)546-0300
>>
>> xxxxx@sciencepark.co.jp wrote:
>>> Our file system filter driver traces a file from opening to closing by
>>> using our FCB.
>>> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the last
>>> IRP_MJ_CLOSE.
>>> It identifies each file by the value of FCB’s “FileObject->FsContext”
>>> which the file system creates.
>>>
>>> There’s a problem here.
>>> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after
>>> the last IRP_MJ_CLOSE.
>>> This IRP_MJ_WRITE does not pass the filter.
>>>
>>> We’d like to manage FCB synchronizing with the one in the file system.
>>> Does anyone know when the FCB should be deleted on the filter driver? —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Peter
In the circumstance you will not see IRP_MJ_CLOSE for the FileObject and
hence you will never see the SOP NULL in pre close … until the
FCB/FileObject are recycled …
Cheers
Lyndon
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> If caching has been established on any FO pointing to the file then
> inspecting the pointers within the SOP will tell you that there is another
> reference and hence you should not tear down your control structure. Using
> this, in combination with reference counting, will handle this situation.
>
> Pete
>
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> Lyndon J Clarke wrote:
>> Hello Peter
>>
>> I assume you have not experienced the case where a driver below uses
>> IoCreateFileSpecifyDeiceObjectHint so you do not see the file object for
>> that create, ever, and yet cacheing is established against that file
>> object, and yet you see the xCB because you see another file object
>> because a.n.other has opned the file, perhaps before
>> IoCreateFileSpecifyDeviceObjectHint was called. In this case refrence
>> count plus SectionObjectPointers approach cannot discard the xCB related
>> state, ever. Hence you see my first response since no other solution is
>> possible for lgeacy filter in presence of
>> IoCreateFileSpecifyDeviceObjectHint.
>>
>> Best Wishes
>> Lyndon
>>
>> “Peter Scott” wrote in message
>> news:xxxxx@ntfsd…
>>> Sounds like you need to read the article at OSROnline on tracking
>>> context information. If you are a legacy filesystem filter driver, which
>>> it sounds like you are since you are referring to IRP_MJ_xxx vs pre/post
>>> callbacks, then for particular cases you need to check the state of the
>>> Section Object pointers to determine if the IRP_MJ_CLOSE you think is
>>> the ‘last’ one is really the last one.
>>>
>>> I suspect you are hitting the case where a stream fileobject is being
>>> created to initialize caching, per NTFS semantics, and thus your
>>> reference counting approach, if using standard techniques, is off.
>>>
>>> Go to OSROnline and look in the IFS FAQ for the reference counting
>>> article. This will explain what you are seeing.
>>>
>>> Pete
>>>
>>> Kernel Drivers
>>> Windows File System and Device Driver Consulting
>>> www.KernelDrivers.com
>>> (303)546-0300
>>>
>>> xxxxx@sciencepark.co.jp wrote:
>>>> Our file system filter driver traces a file from opening to closing by
>>>> using our FCB.
>>>> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the
>>>> last IRP_MJ_CLOSE.
>>>> It identifies each file by the value of FCB’s “FileObject->FsContext”
>>>> which the file system creates.
>>>>
>>>> There’s a problem here.
>>>> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after
>>>> the last IRP_MJ_CLOSE.
>>>> This IRP_MJ_WRITE does not pass the filter.
>>>>
>>>> We’d like to manage FCB synchronizing with the one in the file system.
>>>> Does anyone know when the FCB should be deleted on the filter
>>>> driver? —
>>>> Questions? First check the IFS FAQ at
>>>> https://www.osronline.com/article.cfm?id=17
>>>>
>>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Right, and this is one benefit, in an indirect way, why caching is
initialized in NTFS using a stream FO. Thus you can be assured that the
last IRP_MJ_CLOSE, that is relevant, will be issued against the SFO when
caching is torn down and CM/MM releases its reference, not the FO from
IoCreateFileSpecifyDeviceObjectHint(). Hence the case we are discussing
will not arise.
If you are sitting above FAT, where it does not use an SFO for cache
initialization, then you are correct, you can lose a reference and need
to do cleanup in a secondary manner when the SOP is re-used.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
Lyndon J Clarke wrote:
Peter
In the circumstance you will not see IRP_MJ_CLOSE for the FileObject and
hence you will never see the SOP NULL in pre close … until the
FCB/FileObject are recycled …
Cheers
Lyndon
“Peter Scott” wrote in message
> news:xxxxx@ntfsd…
>> If caching has been established on any FO pointing to the file then
>> inspecting the pointers within the SOP will tell you that there is another
>> reference and hence you should not tear down your control structure. Using
>> this, in combination with reference counting, will handle this situation.
>>
>> Pete
>>
>> Kernel Drivers
>> Windows File System and Device Driver Consulting
>> www.KernelDrivers.com
>> (303)546-0300
>>
>> Lyndon J Clarke wrote:
>>> Hello Peter
>>>
>>> I assume you have not experienced the case where a driver below uses
>>> IoCreateFileSpecifyDeiceObjectHint so you do not see the file object for
>>> that create, ever, and yet cacheing is established against that file
>>> object, and yet you see the xCB because you see another file object
>>> because a.n.other has opned the file, perhaps before
>>> IoCreateFileSpecifyDeviceObjectHint was called. In this case refrence
>>> count plus SectionObjectPointers approach cannot discard the xCB related
>>> state, ever. Hence you see my first response since no other solution is
>>> possible for lgeacy filter in presence of
>>> IoCreateFileSpecifyDeviceObjectHint.
>>>
>>> Best Wishes
>>> Lyndon
>>>
>>> “Peter Scott” wrote in message
>>> news:xxxxx@ntfsd…
>>>> Sounds like you need to read the article at OSROnline on tracking
>>>> context information. If you are a legacy filesystem filter driver, which
>>>> it sounds like you are since you are referring to IRP_MJ_xxx vs pre/post
>>>> callbacks, then for particular cases you need to check the state of the
>>>> Section Object pointers to determine if the IRP_MJ_CLOSE you think is
>>>> the ‘last’ one is really the last one.
>>>>
>>>> I suspect you are hitting the case where a stream fileobject is being
>>>> created to initialize caching, per NTFS semantics, and thus your
>>>> reference counting approach, if using standard techniques, is off.
>>>>
>>>> Go to OSROnline and look in the IFS FAQ for the reference counting
>>>> article. This will explain what you are seeing.
>>>>
>>>> Pete
>>>>
>>>> Kernel Drivers
>>>> Windows File System and Device Driver Consulting
>>>> www.KernelDrivers.com
>>>> (303)546-0300
>>>>
>>>> xxxxx@sciencepark.co.jp wrote:
>>>>> Our file system filter driver traces a file from opening to closing by
>>>>> using our FCB.
>>>>> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the
>>>>> last IRP_MJ_CLOSE.
>>>>> It identifies each file by the value of FCB’s “FileObject->FsContext”
>>>>> which the file system creates.
>>>>>
>>>>> There’s a problem here.
>>>>> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even after
>>>>> the last IRP_MJ_CLOSE.
>>>>> This IRP_MJ_WRITE does not pass the filter.
>>>>>
>>>>> We’d like to manage FCB synchronizing with the one in the file system.
>>>>> Does anyone know when the FCB should be deleted on the filter
>>>>> driver? —
>>>>> Questions? First check the IFS FAQ at
>>>>> https://www.osronline.com/article.cfm?id=17
>>>>>
>>>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Peter
This the behaviour I had hoped for from NTFS; however I have seen the exact
case we discuss with NTFS.
Cheers
Lyndon
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Right, and this is one benefit, in an indirect way, why caching is
> initialized in NTFS using a stream FO. Thus you can be assured that the
> last IRP_MJ_CLOSE, that is relevant, will be issued against the SFO when
> caching is torn down and CM/MM releases its reference, not the FO from
> IoCreateFileSpecifyDeviceObjectHint(). Hence the case we are discussing
> will not arise.
>
> If you are sitting above FAT, where it does not use an SFO for cache
> initialization, then you are correct, you can lose a reference and need to
> do cleanup in a secondary manner when the SOP is re-used.
>
> Pete
>
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> Lyndon J Clarke wrote:
>> Peter
>>
>> In the circumstance you will not see IRP_MJ_CLOSE for the FileObject and
>> hence you will never see the SOP NULL in pre close … until the
>> FCB/FileObject are recycled …
>>
>> Cheers
>> Lyndon
>>
>> “Peter Scott” wrote in message
>> news:xxxxx@ntfsd…
>>> If caching has been established on any FO pointing to the file then
>>> inspecting the pointers within the SOP will tell you that there is
>>> another reference and hence you should not tear down your control
>>> structure. Using this, in combination with reference counting, will
>>> handle this situation.
>>>
>>> Pete
>>>
>>> Kernel Drivers
>>> Windows File System and Device Driver Consulting
>>> www.KernelDrivers.com
>>> (303)546-0300
>>>
>>> Lyndon J Clarke wrote:
>>>> Hello Peter
>>>>
>>>> I assume you have not experienced the case where a driver below uses
>>>> IoCreateFileSpecifyDeiceObjectHint so you do not see the file object
>>>> for that create, ever, and yet cacheing is established against that
>>>> file object, and yet you see the xCB because you see another file
>>>> object because a.n.other has opned the file, perhaps before
>>>> IoCreateFileSpecifyDeviceObjectHint was called. In this case refrence
>>>> count plus SectionObjectPointers approach cannot discard the xCB
>>>> related state, ever. Hence you see my first response since no other
>>>> solution is possible for lgeacy filter in presence of
>>>> IoCreateFileSpecifyDeviceObjectHint.
>>>>
>>>> Best Wishes
>>>> Lyndon
>>>>
>>>> “Peter Scott” wrote in message
>>>> news:xxxxx@ntfsd…
>>>>> Sounds like you need to read the article at OSROnline on tracking
>>>>> context information. If you are a legacy filesystem filter driver,
>>>>> which it sounds like you are since you are referring to IRP_MJ_xxx vs
>>>>> pre/post callbacks, then for particular cases you need to check the
>>>>> state of the Section Object pointers to determine if the IRP_MJ_CLOSE
>>>>> you think is the ‘last’ one is really the last one.
>>>>>
>>>>> I suspect you are hitting the case where a stream fileobject is being
>>>>> created to initialize caching, per NTFS semantics, and thus your
>>>>> reference counting approach, if using standard techniques, is off.
>>>>>
>>>>> Go to OSROnline and look in the IFS FAQ for the reference counting
>>>>> article. This will explain what you are seeing.
>>>>>
>>>>> Pete
>>>>>
>>>>> Kernel Drivers
>>>>> Windows File System and Device Driver Consulting
>>>>> www.KernelDrivers.com
>>>>> (303)546-0300
>>>>>
>>>>> xxxxx@sciencepark.co.jp wrote:
>>>>>> Our file system filter driver traces a file from opening to closing
>>>>>> by using our FCB.
>>>>>> It creates FCB at the first IRP_MJ_CREATE, and then delete it at the
>>>>>> last IRP_MJ_CLOSE.
>>>>>> It identifies each file by the value of FCB’s “FileObject->FsContext”
>>>>>> which the file system creates.
>>>>>>
>>>>>> There’s a problem here.
>>>>>> In case of mapped file I/O, cache manager calls IRP_MJ_WRITE even
>>>>>> after the last IRP_MJ_CLOSE.
>>>>>> This IRP_MJ_WRITE does not pass the filter.
>>>>>>
>>>>>> We’d like to manage FCB synchronizing with the one in the file
>>>>>> system.
>>>>>> Does anyone know when the FCB should be deleted on the filter
>>>>>> driver? —
>>>>>> Questions? First check the IFS FAQ at
>>>>>> https://www.osronline.com/article.cfm?id=17
>>>>>>
>>>>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>>
>>>>
>>>> —
>>>> Questions? First check the IFS FAQ at
>>>> https://www.osronline.com/article.cfm?id=17
>>>>
>>>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>