OK so my managers are interested in porting our disk file filter driver to a minifilter. Our legacy style driver compresses the stream for particular files and as well fools the creating appilcation into seeing the uncompressed size instead of compressed size. Encryption of the stream is an option as well. So I never actually pass the original IRP through, instead creating my own and compressing/encrypting into it (and writing to an index file we create) and completing the original once mine are done.
So my question is, will I run into any issues porting this compression and encryption filter driver to a minifilter? For example will I be able to prevent certain IO/IRPs from traveling further down the driver stack like that until my own IO to that same file has completed. Any other issues?
Sorry for basic questions like this. Just looking for any huge problem/warning.
It *should* not be a big deal to port any existing filter from legacy to
Minifilter. Indeed I am guessing that if there are any issues the
Minifilter devs at MS would want to know so that they can help you - they
really really really want people to do this.
You biggest work item (probably) be that AFAIK there is but one API in the
Minifilter which takes and IRP and so all your IRP manipulation is going to
have to be converted to PFLT_CALLBACK_DATA manipulation.
Having done a few of these, I’d suggest that if possible you go for a hybrid
approach (part legacy, part Minifilter) during conversion. At any
particular stage some functions are done legacy, and some are done
Minifilter. You can then move each MJ_FUNCTION over individually and do a
smoke test at each stage. After a while converting a function becomes quite
mechanical.
Start with the easy IRPS (SET_SECURITY) and work through to end up with
CREATE/CLEANUP). At that stage you can look to see whether filter manager
can buy you some simplification (Stream Handle contexts can be nice, as
could file contexts if you are willing to be Vista and later only).
I’d also say that you should treat the mount/unmount path with caution.
Finally - you may will need to implement the name provider APIs - even if it
is just to keep the verifier happy in Win7. These do not have the best docs
in the world. However you can leave that 'til last since you will be OK
without them until interop/stress testing.
Rod
Steading System Software
wrote in message news:xxxxx@ntfsd…
> OK so my managers are interested in porting our disk file filter driver to
> a minifilter. Our legacy style driver compresses the stream for particular
> files and as well fools the creating appilcation into seeing the
> uncompressed size instead of compressed size. Encryption of the stream is
> an option as well. So I never actually pass the original IRP through,
> instead creating my own and compressing/encrypting into it (and writing to
> an index file we create) and completing the original once mine are done.
>
> So my question is, will I run into any issues porting this compression and
> encryption filter driver to a minifilter? For example will I be able to
> prevent certain IO/IRPs from traveling further down the driver stack like
> that until my own IO to that same file has completed. Any other issues?
> Sorry for basic questions like this. Just looking for any huge
> problem/warning.
>