Hi,
Under certain conditions my filter needs to deny access for create requests
and this requires my filter driver to be able to get the fscontext for the
create, if exists from a previous create. Obviously I need to do this in the
fastest way possible.
Which is the preferred, recommended and correct way to achieve this in the
Create path? I think the best is to wait until PostCreate callback and then
issue the FltCancelFileOpen when after fscontext inspection I need to deny
access to the file.
The other alternative is in PreCreate to reuse the original request with an
own stream file object or use FltCreateFile, but it´s not an option because
this implies a new open for a lot of files and a huge impact on performance.
The last year an issue was identified that could arise when IoCancelFileOpen
is called, and my tests show this seems to be applicable to
FltCancelFileOpen too. The workaround from OSR and Microsoft assume that
excepting “stack based” file objects it is correct to perform an IRP_MJ_READ
or IRP_MJ_WRITE operation with the file object from the IRP_MJ_CREATE,
including creates for compressed files.
Recently I have found that the scanner minifilter included in the last 2003
IFSKIT uses FltCancelFileOpen, and this seems to be no compatible with
incrementing the reference count of the file object passed to IRP_MJ_READ in
a lower filter.
What is then supposed to be the forbidden operation?
Thanks.
mK.
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
Misha,
As you said the best way to achieve what you are looking for is to wait
until PostCreate and then issue FltCancelFileOpen after you have determined
that you want to deny access to this file. This is best from a performance
point of you. There was a bug in IoCancelFileOpen and FltCancelFileOpen
which would cause the system to crash if a cached I/O was done and the Cache
Manager had a reference to this file object. This has been fixed in Windows
Server 2003 SP1 and Windows XP SP2 so now you can safely call these
routines.
Thanks
Ravinder Thind
This posting is provided "AS IS" with no warranties, and confers no rights.
"Misha Karpin" wrote in message
news:xxxxx@ntfsd...
> Hi,
>
> Under certain conditions my filter needs to deny access for create
requests
> and this requires my filter driver to be able to get the fscontext for the
> create, if exists from a previous create. Obviously I need to do this in
the
> fastest way possible.
>
> Which is the preferred, recommended and correct way to achieve this in the
> Create path? I think the best is to wait until PostCreate callback and
then
> issue the FltCancelFileOpen when after fscontext inspection I need to deny
> access to the file.
>
> The other alternative is in PreCreate to reuse the original request with
an
> own stream file object or use FltCreateFile, but it´s not an option
because
> this implies a new open for a lot of files and a huge impact on
performance.
>
> The last year an issue was identified that could arise when
IoCancelFileOpen
> is called, and my tests show this seems to be applicable to
> FltCancelFileOpen too. The workaround from OSR and Microsoft assume that
> excepting "stack based" file objects it is correct to perform an
IRP_MJ_READ
> or IRP_MJ_WRITE operation with the file object from the IRP_MJ_CREATE,
> including creates for compressed files.
>
> Recently I have found that the scanner minifilter included in the last
2003
> IFSKIT uses FltCancelFileOpen, and this seems to be no compatible with
> incrementing the reference count of the file object passed to IRP_MJ_READ
in
> a lower filter.
>
> What is then supposed to be the forbidden operation?
>
> Thanks.
>
> mK.
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>