I have a weird filter / redirector and am looking for a solution to a
problem. I at time create my own FCB’s with their own structure this works
fine, except when you get to the routines filtered with
FsRtlRegisterFileSystemFilterCallbacks, since there is no way to indicate
“I’ve taken care of do not proceed down the filter chain”.
Does anyone have any suggestions on how to handle these cases? There are a
number of problems with making the effort a pure redirector and handling
the requests.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Seems like what you want to do is reasonable…
This is a shot in the dark since I don’t know anything about what you
are doing; would clearing (set to NULL) your FCB values prior to
returning from the PreXxxx() callbacks and then re-establishing the FCB
on the PostXxxx() callbacks get you somewhere? Or would that cause a
bunch of other headaches?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, March 07, 2007 11:24 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FsRtlRegisterFileSystemFilterCallbacks and
controlling callbacks
I have a weird filter / redirector and am looking for a solution to a
problem. I at time create my own FCB’s with their own structure this
works
fine, except when you get to the routines filtered with
FsRtlRegisterFileSystemFilterCallbacks, since there is no way to
indicate
“I’ve taken care of do not proceed down the filter chain”.
Does anyone have any suggestions on how to handle these cases? There
are a
number of problems with making the effort a pure redirector and
handling
the requests.
Well I have an FCB that is different size and id than NTFS’s unforunately
it seems the code for this stuff ignores the header values and knows this
is an NTFS FCB, so there is no way to put the values to something NTFS will
accept.
What I really want to do is in the PreXXX callback indicate I have
completed the operation, but the FsRtlRegisterFileSystemFilterCallbacks
appears to have no ability to do so, and therefore filter manager ignores
the FLT_PREOP_COMPLETE on these calls.
If nothing else this is a documetation bug, since the Filter Manager
documentation does not identify these as having different functionality
than other callback with respect to the return status.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Vossen, Joseph (ISS Atlanta)” wrote in message
news:xxxxx@ntfsd…
Seems like what you want to do is reasonable…
This is a shot in the dark since I don’t know anything about what you
are doing; would clearing (set to NULL) your FCB values prior to
returning from the PreXxxx() callbacks and then re-establishing the FCB
on the PostXxxx() callbacks get you somewhere? Or would that cause a
bunch of other headaches?
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Wednesday, March 07, 2007 11:24 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] FsRtlRegisterFileSystemFilterCallbacks and
> controlling callbacks
>
>
> I have a weird filter / redirector and am looking for a solution to a
> problem. I at time create my own FCB’s with their own structure this
works
> fine, except when you get to the routines filtered with
> FsRtlRegisterFileSystemFilterCallbacks, since there is no way to
indicate
> “I’ve taken care of do not proceed down the filter chain”.
>
> Does anyone have any suggestions on how to handle these cases? There
are a
> number of problems with making the effort a pure redirector and
handling
> the requests.
Well, that functionality is “special cased” as implied by the
non-standard (negative) IRP values. Best case for you it is a Filter
Manager bug and will be fixed, worst case it’s a doc error. I guess I’m
not very helpful today…
Does your post-operation callback get invoked (it shouldn’t) even when
you return FLT_PREOP_COMPLETE?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, March 07, 2007 12:49 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FsRtlRegisterFileSystemFilterCallbacks
and controlling callbacks
Well I have an FCB that is different size and id than NTFS’s
unforunately
it seems the code for this stuff ignores the header values and knows
this
is an NTFS FCB, so there is no way to put the values to something NTFS
will
accept.
What I really want to do is in the PreXXX callback indicate I have
completed the operation, but the
FsRtlRegisterFileSystemFilterCallbacks
appears to have no ability to do so, and therefore filter manager
ignores
the FLT_PREOP_COMPLETE on these calls.
If nothing else this is a documetation bug, since the Filter Manager
documentation does not identify these as having different
functionality
than other callback with respect to the return status.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Vossen, Joseph (ISS Atlanta)” wrote in message
> news:xxxxx@ntfsd…
> Seems like what you want to do is reasonable…
>
> This is a shot in the dark since I don’t know anything about
> what you are doing; would clearing (set to NULL) your FCB
> values prior to returning from the PreXxxx() callbacks and
> then re-establishing the FCB on the PostXxxx() callbacks get
> you somewhere? Or would that cause a bunch of other headaches?
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> > Sent: Wednesday, March 07, 2007 11:24 AM
> > To: Windows File Systems Devs Interest List
> > Subject: [ntfsd] FsRtlRegisterFileSystemFilterCallbacks and
> > controlling callbacks
> >
> >
> > I have a weird filter / redirector and am looking for a solution to
a
> > problem. I at time create my own FCB’s with their own structure
this works
> > fine, except when you get to the routines filtered with
> > FsRtlRegisterFileSystemFilterCallbacks, since there is no way to
indicate
> > “I’ve taken care of do not proceed down the filter chain”.
> >
> > Does anyone have any suggestions on how to handle these cases?
There are a
> > number of problems with making the effort a pure redirector and
handling
> > the requests.
> since there is no way to indicate "I’ve taken care of do not proceed down
the filter chain".
There is an undocumented in WDK( but documented in ntstatus.h ) status code
STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY 0x00000126. If you return this
code the underlying filters and FSD will not be called.
–
Slava Imameyev, xxxxx@hotmail.com
“Don Burn” wrote in message news:xxxxx@ntfsd…
>I have a weird filter / redirector and am looking for a solution to a
>problem. I at time create my own FCB’s with their own structure this works
>fine, except when you get to the routines filtered with
>FsRtlRegisterFileSystemFilterCallbacks, since there is no way to indicate
>“I’ve taken care of do not proceed down the filter chain”.
>
> Does anyone have any suggestions on how to handle these cases? There are
> a number of problems with making the effort a pure redirector and handling
> the requests.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
That’s nice to know…thanks for the pointer.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Wednesday, March 07, 2007 5:06 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FsRtlRegisterFileSystemFilterCallbacks
and controlling callbacks
> since there is no way to indicate "I’ve taken care of do not proceed
> down the filter chain".
There is an undocumented in WDK( but documented in ntstatus.h ) status
code
STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY 0x00000126. If you return
this
code the underlying filters and FSD will not be called.
–
Slava Imameyev, xxxxx@hotmail.com
“Don Burn” wrote in message news:xxxxx@ntfsd…
> >I have a weird filter / redirector and am looking for a solution to a
> >problem. I at time create my own FCB’s with their own structure this
works
> >fine, except when you get to the routines filtered with
> >FsRtlRegisterFileSystemFilterCallbacks, since there is no way to
indicate
> >“I’ve taken care of do not proceed down the filter chain”.
> >
> > Does anyone have any suggestions on how to handle these cases?
There
> > are a number of problems with making the effort a pure redirector
and handling
> > the requests.
You should return an undocumented status code
STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY. This is defined in NTSTATUS.H
file and used in the WDK CDFS and FastFAT examples specifically for
Windows Vista. But be careful because at least Windows XP and Windows XP
SP1 don’t check and recognize (i.e. simply ignore it) this status code
and do pass incoming requests to next filters (if any are registered)
and a base file system in a chain. So in this case you should think of
another method of processing these callbacks (for example, using a Fast
I/O table, this technique was described here some years ago).
Also, as I think, you should pay attention to two new status codes which
were introduced in Windows Vista:
STATUS_FILE_LOCKED_WITH_ONLY_READERS (The file was locked and all users
of the file can only read) and STATUS_FILE_LOCKED_WITH_WRITERS (The file
was locked and at least one user of the file can write). These status
codes are only used in PreAcquireForSectionSynchronization routine and
depends on SyncType parameter from the CallbackData structure. For
details look at CDFS and FastFAT examples from the Vista WDK. But
nevertheless I’m still very interested in more details about these
status codes.
In addition I’d like to say that some times I observed strange behavior
(and as a result BSOD with RESOURCE_NOT_OWNED) on Windows Vista for
PreAcquireForSectionSynchronization routine. This routine from NTFS
driver acquired only one resource (paging) and then
ReleaseForSectionSynchronization request was passed to the default
kernel handle which tried to release both resources, main and paging
which finally resulted in the described BSOD. All file object’s FCBs for
which such behavior was observed were private to NTFS driver and were
simply passed thru my driver, in other words I didn’t perform any
actions on these FCBs.
Think it will help you someway.
With best regards,
Konstantin Manurin
System Programmer
I have a weird filter / redirector and am looking for a solution to a
problem. I at time create my own FCB’s with their own structure this works
fine, except when you get to the routines filtered with
FsRtlRegisterFileSystemFilterCallbacks, since there is no way to indicate
“I’ve taken care of do not proceed down the filter chain”.
Does anyone have any suggestions on how to handle these cases? There are a
number of problems with making the effort a pure redirector and handling
the requests.