Hello everyone,
I have read the WDK documentation of Minifilter and saw the long list of advantages of using a minifilter over a legacy filter.
But can anyone tell me what are the limitations of using a minifilter?
In which scenario is the Legacy filter still preferable over Minifilter?
Thanks in advance.
Tushar
I am not an expert regarding minifilters, but there might be problem that you can attach only to FSDs which support per stream contexts in FCBs. In other words when FSD doesn’t use in FCBs properly initialized FSRTL_ADVANCED_FCB_HEADER structure, you cannot attach to its devices with minifilter. This is only case of 3rd-party FSDs. Can someone confirm/refute my assumption.
-bg
Hello Tushar,
In general, you should write minifilters until you find something
specifically that doesn’t work right. There are some bugs in the filter
manager, but in general these can be overcome using legacy techniques.
As I see it, the primary limitations are the service pack levels,
mini-filters require w2k sp4 + URP1 (or sp4 + the FLTMGR update obtained
only from MS support), or XP sp2, server 2003 sp1, or Vista.
One place a legacy filter would be mandatory would be with NT4,
lately there have been a lot of questions about this old OS. FltMgr is
not supported at all with this OS.
Given the fact that MS has declared that in a few years legacy
filters will not be supported, you should go with a mini-filter if you
want your code to live in the future.
Regarding bugs in the fltmgr, most are not an issue for filters
running locally. There are some with flt functions, but they
can be overcome quite easily.
Regards,
Matthew
xxxxx@gmail.com wrote:
>Hello everyone,
>
>I have read the WDK documentation of Minifilter and saw the long list of advantages of using a minifilter over a legacy filter.
>But can anyone tell me what are the limitations of using a minifilter?
>In which scenario is the Legacy filter still preferable over Minifilter?
>
>Thanks in advance.
>Tushar
>
>—
>NTFSD is sponsored by OSR
>
>For our schedule debugging and file system seminars
>(including our new fs mini-filter seminar) visit:
>http://www.osr.com/seminars
>
>You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
No Sir,
A mini-filter can still attach and filter, just it’s context functions
will not work. To attach a stream context, or a stream handle context,
the file system must use the
FSRTL_ADVANCED_FCB_HEADER structure. Otherwise, if will work, just can’t attach a context to a stream.
Matthew
xxxxx@xythos.com wrote:
I am not an expert regarding minifilters, but there might be problem that you can attach only to FSDs which support per stream contexts in FCBs. In other words when FSD doesn’t use in FCBs properly initialized FSRTL_ADVANCED_FCB_HEADER structure, you cannot attach to its devices with minifilter. This is only case of 3rd-party FSDs. Can someone confirm/refute my assumption.
-bg
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
In general use a mini-filter, but the model is deficient in some areas. One
big one is that it is imposible to get the original IRP and reroute it, so
for instance mirroring a file can be more painful than it needs to be.
Also, the ability to send requests down the stack is nice, but highly
incosistant. I did a mini-filter where it could redirect requests to
another instance of the driver on another machine, by the end of the project
I strongly wished I had ignored mini-filters and done the whole thing with a
legacy model.
Finally, mini-filters do not address a lot of the tough problems in
filtering, for instance how about help in supporting a seconday file object?
I know there are others, but it is still early for me.
–
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
wrote in message news:xxxxx@ntfsd…
> Hello everyone,
>
> I have read the WDK documentation of Minifilter and saw the long list of
> advantages of using a minifilter over a legacy filter.
> But can anyone tell me what are the limitations of using a minifilter?
> In which scenario is the Legacy filter still preferable over Minifilter?
>
> Thanks in advance.
> Tushar
>
Don,
Curious as to why you say, “mirroring a file can be more painful than it
needs to be.”
Why would this be more difficult in a mini than a legacy?
Matthew
Don Burn wrote:
In general use a mini-filter, but the model is deficient in some areas. One
big one is that it is imposible to get the original IRP and reroute it, so
for instance mirroring a file can be more painful than it needs to be.
Also, the ability to send requests down the stack is nice, but highly
incosistant. I did a mini-filter where it could redirect requests to
another instance of the driver on another machine, by the end of the project
I strongly wished I had ignored mini-filters and done the whole thing with a
legacy model.Finally, mini-filters do not address a lot of the tough problems in
filtering, for instance how about help in supporting a seconday file object?
I know there are others, but it is still early for me.
Matthew,
Because in a legacy case I can send the IRP to one stack (doing a
couple of minor alterations) then send it to the other. You cannot do this
with a mini-filter since you cannot alter the target.
Worse yet things like FltPerformXXXIo are extremely limited (though not
documented that it is so limited) as to what calls it supports, so you
cannot just clone the request and fire it off on the other stack. To add to
the misery the FltCreateFile and related calls do not cover the whole
spectrum of requests or for that matter even the requests that there are Zw
calls for. So there is no way to use the “no recursion” feature of
mini-filters if you are doing things out of the ordinary.
I have now completed two mini-filters for clients, and in both cases I
could have done a better job with a legacy filter. In the first case I
believed the hype, in the second case the client and I discussed it at
length and decided that even though the mini-filter added overhead in a
critical path, the long term threat of Microsoft requiring mini-filters made
it a better choice.
I think the mini-filter model is a good start, but Microsoft needs to
put A LOT MORE EFFORT into the model before it real. It was interesting
talking to multiple people I respect a lot at the last WinHEC about
mini-filters, more than once the sentiment was “they handle all the easy
things, and left all the hard stuff as an exercise for the developer”.
–
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
“MM” wrote in message news:xxxxx@ntfsd…
> Don,
>
> Curious as to why you say, “mirroring a file can be more painful than it
> needs to be.”
>
> Why would this be more difficult in a mini than a legacy?
>
> Matthew
>
> Don Burn wrote:
>
>>In general use a mini-filter, but the model is deficient in some areas.
>>One big one is that it is imposible to get the original IRP and reroute
>>it, so for instance mirroring a file can be more painful than it needs to
>>be. Also, the ability to send requests down the stack is nice, but highly
>>incosistant. I did a mini-filter where it could redirect requests to
>>another instance of the driver on another machine, by the end of the
>>project I strongly wished I had ignored mini-filters and done the whole
>>thing with a legacy model.
>>
>>Finally, mini-filters do not address a lot of the tough problems in
>>filtering, for instance how about help in supporting a seconday file
>>object? I know there are others, but it is still early for me.
>>
>>
>>
>
Well damn, you got me there… 
But as far as I know, you can still
build an IRP rather easily
from the info in the callback’s data structure.
I’ve never tried this, but I believe it’s possible. I wouldn’t throw out
all the advantages of a mini-filter
just because a few things have to be done the old way. Combining
technologies in my experience
has always been a good thing.
Since I’ve never tried this, what all issues are there (other than the
legacy methods) to be considered
here?
Matthew
Don Burn wrote:
Matthew,
Because in a legacy case I can send the IRP to one stack (doing a
couple of minor alterations) then send it to the other. You cannot do this
with a mini-filter since you cannot alter the target.Worse yet things like FltPerformXXXIo are extremely limited (though not
documented that it is so limited) as to what calls it supports, so you
cannot just clone the request and fire it off on the other stack. To add to
the misery the FltCreateFile and related calls do not cover the whole
spectrum of requests or for that matter even the requests that there are Zw
calls for. So there is no way to use the “no recursion” feature of
mini-filters if you are doing things out of the ordinary.I have now completed two mini-filters for clients, and in both cases I
could have done a better job with a legacy filter. In the first case I
believed the hype, in the second case the client and I discussed it at
length and decided that even though the mini-filter added overhead in a
critical path, the long term threat of Microsoft requiring mini-filters made
it a better choice.I think the mini-filter model is a good start, but Microsoft needs to
put A LOT MORE EFFORT into the model before it real. It was interesting
talking to multiple people I respect a lot at the last WinHEC about
mini-filters, more than once the sentiment was “they handle all the easy
things, and left all the hard stuff as an exercise for the developer”.
To expand on my comments from the last couple of posts, at a minimum I hope
Microsoft will add the following to mini-filters:
Fix FltPerformXXXIo so that all requests can be composed and forwarded
to lower levels. The current restriction to a subset of the FltXXX handle
calls is a total joke.
Add support for secondary file objects to remove a lot of the drudgery
out this.
Add support for data modification. Maybe this is pay OSR a lot of money
and buy their kit, but the bottom line is that modification of data is
common and still very hard. This is where a lot of the bugs occur.
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
Matthew,
You can build your IRP, but then you have to choose, send it to all
the filters in the stack by going to the top of the stack, or bypass all the
mini-filters below you since you cannot send it the next mini-filter.
Either choice is full of problems, and can break things rather badly. This
is why if I had the chance to do it over again, I would go legacy on my
first filter, since in the end we decided that we would not guarantee things
work if a mini-filter was below us. On the second mini-filter I did roll my
own IRP’s but what I was filtering was PAGING, adding any overhead here
pains me greatly.
–
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
“MM” wrote in message news:xxxxx@ntfsd…
> Well damn, you got me there… But as far as I know, you can still
> build an IRP rather easily
> from the info in the callback’s data structure.
>
> I’ve never tried this, but I believe it’s possible. I wouldn’t throw out
> all the advantages of a mini-filter
> just because a few things have to be done the old way. Combining
> technologies in my experience
> has always been a good thing.
>
> Since I’ve never tried this, what all issues are there (other than the
> legacy methods) to be considered
> here?
>
> Matthew
>
Excellent points.
You are indeed a great teacher. I’ve build several filters now, but
never ran into any of these problems.
As an exercise, what would you consider the three most difficult types
of mini-filters to build? I would
enjoy the challenge from someone such as yourself.
Matt
Don Burn wrote:
Matthew,
You can build your IRP, but then you have to choose, send it to all
the filters in the stack by going to the top of the stack, or bypass all the
mini-filters below you since you cannot send it the next mini-filter.
Either choice is full of problems, and can break things rather badly. This
is why if I had the chance to do it over again, I would go legacy on my
first filter, since in the end we decided that we would not guarantee things
work if a mini-filter was below us. On the second mini-filter I did roll my
own IRP’s but what I was filtering was PAGING, adding any overhead here
pains me greatly.
Not to jump into the middle of the thread, but has anybody looked to see
if any of the structures pointed to by the FLT_CALLBACK_DATA structure
actually live in the IRP? If they were, you could probably get your
paws on the IRP using CONTAINING RECORD.
Alternately, I discovered as I was debugging something in a CSQ that the
FLT_CALLBACK_DATA_QUEUE_IO_CONTEXT is really just a typedef for a
IO_CSQ_IRP_CONTEXT. Which contains pointer to the irp. If you were
really desperate, you could probably write a dummy queue implementation
to get a pointer to the IRP.
Mind you, I’m not suggesting actually *doing* either of these. Neither
one seems like a good idea, but if you were feeling really adventureous,
it seems like a great possibility for spending a few weeks hunting down
bizarre bugs and generally making your life miserable. Also, both of
these are well into the realm of pulling back the opacity, and would
probably cease working on new versions of Windows anyway.
There you go, two stupid ideas for the price of one 
Of course, even if this would work, it still doesn’t solve the problem
of sending the IRP to the right place once you have it.
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 17, 2007 9:56 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] What are the limitations of Minifilter
Matthew,
You can build your IRP, but then you have to choose, send it to
all the filters in the stack by going to the top of the stack, or bypass
all the mini-filters below you since you cannot send it the next
mini-filter.
Either choice is full of problems, and can break things rather badly.
This is why if I had the chance to do it over again, I would go legacy
on my first filter, since in the end we decided that we would not
guarantee things work if a mini-filter was below us. On the second
mini-filter I did roll my own IRP’s but what I was filtering was PAGING,
adding any overhead here pains me greatly.
–
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
“MM” wrote in message news:xxxxx@ntfsd…
> Well damn, you got me there… But as far as I know, you can
still
> build an IRP rather easily
> from the info in the callback’s data structure.
>
> I’ve never tried this, but I believe it’s possible. I wouldn’t throw
out
> all the advantages of a mini-filter
> just because a few things have to be done the old way. Combining
> technologies in my experience
> has always been a good thing.
>
> Since I’ve never tried this, what all issues are there (other than the
> legacy methods) to be considered
> here?
>
> Matthew
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Matt,
I am going to defer this to Tony Mason and others since I have not really
done enough file system filter driver work to call myself an expert. My
filters have been pretty simple except for the first mini-filter which was
very complex. Ironically, I have spent more time on file systems for
Windows than filters.
–
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
“MM” wrote in message news:xxxxx@ntfsd…
> Excellent points.
>
> You are indeed a great teacher. I’ve build several filters now, but never
> ran into any of these problems.
>
> As an exercise, what would you consider the three most difficult types of
> mini-filters to build? I would
> enjoy the challenge from someone such as yourself.
>
> Matt
>
Eric,
The one time I looked the flt manager was inconsistent on this, i.e.
the answer is sometimes in some cases. The flt manager is great for
filemon type drivers, but bottom line that is not where the problems are
today. Flt manager makes the file system stack reliability WORSE, since it
makes it look easy to do a filter driver. I know of a firm who wanted “a
little help to get started”, they had a person who never worked in the
kernel and were trying to do a very complex encryption filter with a few
redirection like things thrown in. I recommended going to OSR for the
whole project or at a minimum the data modifciation kit. They rejected the
suggestion since their schedule and budget did not permit it. Fortunately,
they still have not released a product, I doubt they ever will.
–
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
“Eric Diven” wrote in message news:xxxxx@ntfsd…
Not to jump into the middle of the thread, but has anybody looked to see
if any of the structures pointed to by the FLT_CALLBACK_DATA structure
actually live in the IRP? If they were, you could probably get your
paws on the IRP using CONTAINING RECORD.
Alternately, I discovered as I was debugging something in a CSQ that the
FLT_CALLBACK_DATA_QUEUE_IO_CONTEXT is really just a typedef for a
IO_CSQ_IRP_CONTEXT. Which contains pointer to the irp. If you were
really desperate, you could probably write a dummy queue implementation
to get a pointer to the IRP.
Mind you, I’m not suggesting actually doing either of these. Neither
one seems like a good idea, but if you were feeling really adventureous,
it seems like a great possibility for spending a few weeks hunting down
bizarre bugs and generally making your life miserable. Also, both of
these are well into the realm of pulling back the opacity, and would
probably cease working on new versions of Windows anyway.
There you go, two stupid ideas for the price of one
Of course, even if this would work, it still doesn’t solve the problem
of sending the IRP to the right place once you have it.
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 17, 2007 9:56 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] What are the limitations of Minifilter
Matthew,
You can build your IRP, but then you have to choose, send it to
all the filters in the stack by going to the top of the stack, or bypass
all the mini-filters below you since you cannot send it the next
mini-filter.
Either choice is full of problems, and can break things rather badly.
This is why if I had the chance to do it over again, I would go legacy
on my first filter, since in the end we decided that we would not
guarantee things work if a mini-filter was below us. On the second
mini-filter I did roll my own IRP’s but what I was filtering was PAGING,
adding any overhead here pains me greatly.
–
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
“MM” wrote in message news:xxxxx@ntfsd…
> Well damn, you got me there… But as far as I know, you can
still
> build an IRP rather easily
> from the info in the callback’s data structure.
>
> I’ve never tried this, but I believe it’s possible. I wouldn’t throw
out
> all the advantages of a mini-filter
> just because a few things have to be done the old way. Combining
> technologies in my experience
> has always been a good thing.
>
> Since I’ve never tried this, what all issues are there (other than the
> legacy methods) to be considered
> here?
>
> Matthew
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Don,
Flt manager makes the file system stack reliability WORSE, since it
makes it look easy to do a filter driver.
Interesting point Don. Can you please give some insight as to why?
Now since a thread of this sort has already started, I would love to jump in
and ask which one of these is best option for file system filtering:
1. Legacy filters.
2. Mini-filter.
3. Legacy filters using OSR’s FDDK
Since, I am not lucky enough to actually use the FDDK ( due to cost factors
), I would love to know what exactly does FDDK offer that makes it
popular? I have even heard people wishing to write a filter using FDDK…
Thanks and regards,
Ayush Gupta.
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Hi Don,
>
>
> Flt manager makes the file system stack reliability WORSE, since it
> makes it look easy to do a filter driver.
>
>
> Interesting point Don. Can you please give some insight as to why?
I make this claim, since mini-filters create the illusion that is much
easier to create a file system filter than it is. What this is doing is
create a situation where companies are jumping into things needing a file
system filter without the people, the budget or a plan on how they are going
to get there or maintain it after the fact.
Unlike WDF which definitely took a number of the nasties out of kernel
driver developlment, mini-filters hide some things (none of which were that
hard) and add challenges due to the limits of the current implementation.
I like mini-filters but they really do not solve any of the hard problems of
filter drivers.
–
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
Thanks Don,
Has anyone any idea of advantages of using the FDDK?
The max that I know about it is that it makes development of legacy filters
a bit easier…
Is it better to develop a mini-filter or use FFDK to develop a legacy
filter?
Sorry for steering the discussion into a slightly different direction,
but does
anyone have data/opinion on the relative performance minifilter vs.
legacy implementation?
In some test cases I’ve seen a minifilter driver overhead being almost
twice of the
legacy one (for a similar functionality, of course). Just curious if
anyone has some
insights on the subject.
Thanks,
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 17, 2007 12:14 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] What are the limitations of Minifilter
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Hi Don,
>
>
> Flt manager makes the file system stack reliability WORSE, since it
> makes it look easy to do a filter driver.
>
>
> Interesting point Don. Can you please give some insight as to why?
I make this claim, since mini-filters create the illusion that is much
easier to create a file system filter than it is. What this is doing
is
create a situation where companies are jumping into things needing a
file
system filter without the people, the budget or a plan on how they are
going
to get there or maintain it after the fact.
Unlike WDF which definitely took a number of the nasties out of kernel
driver developlment, mini-filters hide some things (none of which were
that
hard) and add challenges due to the limits of the current
implementation.
I like mini-filters but they really do not solve any of the hard
problems of
filter drivers.
–
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
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@symantec.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Which function causes the mini-filter’s overhead twice of the legacy one?
Thanks,
“Vitaly Vatnikov” wrote in message
news:xxxxx@ntfsd…
Sorry for steering the discussion into a slightly different direction,
but does
anyone have data/opinion on the relative performance minifilter vs.
legacy implementation?
In some test cases I’ve seen a minifilter driver overhead being almost
twice of the
legacy one (for a similar functionality, of course). Just curious if
anyone has some
insights on the subject.
Thanks,
- Vitaly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 17, 2007 12:14 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] What are the limitations of Minifilter
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Hi Don,
>
>
> Flt manager makes the file system stack reliability WORSE, since it
> makes it look easy to do a filter driver.
>
>
> Interesting point Don. Can you please give some insight as to why?
I make this claim, since mini-filters create the illusion that is much
easier to create a file system filter than it is. What this is doing
is
create a situation where companies are jumping into things needing a
file
system filter without the people, the budget or a plan on how they are
going
to get there or maintain it after the fact.
Unlike WDF which definitely took a number of the nasties out of kernel
driver developlment, mini-filters hide some things (none of which were
that
hard) and add challenges due to the limits of the current
implementation.
I like mini-filters but they really do not solve any of the hard
problems of
filter drivers.
–
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
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@symantec.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
In all our tests the performance of our minifilter implementation was worse than the legacy filter. Of course it may be because or legacy filter is a mature product while our minifilter is not.
I suspect in our case the penalty might be located in the kernel-user communications path (we use the api provided by MS for MF). In our application there is plenty of communication overhead. In other minifilters we have, not as heavy, we did not notice a significant decrease in performance.
I would be interested to hear how well minifilters behave in terms of performance for other applications.
Inaki.
-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de Vitaly Vatnikov
Enviado el: lunes, 17 de diciembre de 2007 20:04
Para: Windows File Systems Devs Interest List
Asunto: RE: [ntfsd] What are the limitations of Minifilter
Sorry for steering the discussion into a slightly different direction,
but does
anyone have data/opinion on the relative performance minifilter vs.
legacy implementation?
In some test cases I’ve seen a minifilter driver overhead being almost
twice of the
legacy one (for a similar functionality, of course). Just curious if
anyone has some
insights on the subject.
Thanks,
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 17, 2007 12:14 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] What are the limitations of Minifilter
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Hi Don,
>
>
> Flt manager makes the file system stack reliability WORSE, since it
> makes it look easy to do a filter driver.
>
>
> Interesting point Don. Can you please give some insight as to why?
I make this claim, since mini-filters create the illusion that is much
easier to create a file system filter than it is. What this is doing
is
create a situation where companies are jumping into things needing a
file
system filter without the people, the budget or a plan on how they are
going
to get there or maintain it after the fact.
Unlike WDF which definitely took a number of the nasties out of kernel
driver developlment, mini-filters hide some things (none of which were
that
hard) and add challenges due to the limits of the current
implementation.
I like mini-filters but they really do not solve any of the hard
problems of
filter drivers.
–
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
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@symantec.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com