> I just wonder if it can be done within a mini-filter driver?
Oh yes. It is exactly the same task, with the additional headache of name
providers.
- Is it possible to implement same features (double FCBs) in one mini
filter driver?
Absolutely. I’d also allocate my own CCB (FsContext2).
- I have read following post:
http://www.osronline.com/showThread.cfm?link=175501
http://www.osronline.com/showThread.cfm?link=189802
I’d also look at http://www.osronline.com/article.cfm?article=560 It says
part 1…
Here is my understanding:
a. Allocate memory (sizeof(FSRTL_ADVANCED_HEADER)) for a new FsContext
Plus all the other stuff you need for yourself (remember this is also
going to be your StreamContext - indeed you might want to make it the
StreamContext for the lower file objects))
b) Allocate a data structure for FsContext2
b. When the IRP is passed to lower driver (FSD, etc), replace
FO->FsContext with the original one. (The original one contains cipher
text)
That might work, but I wouldn’t do it. I’d complete the IRP (return
FLT_PREOP_COMPLETE). This means that in the intervening time you call
FltXXX to do the work at the lower file system API filling in FsContext and
FsContext2 as required. This also means that in create you assign your data
structures to Fo->FsContext & Fo->FsContext2.
You are now juggling two file objects and in some all you need to do is
replace Data->TargetFileObject and return FLT_PREOP_COMPLETE_XXX (this is
analogous to copying the stack down and replacing IrpSp->FileObject.
When the IRP is passed to higher driver (higher level filter driver,
etc), replace FO->FsContext with the new one. (The new one contains plain
text)
You don’t need to do this.
Is it doable?
I’ve done what I describe above for clients, so yes, very. You should allow
about a fair bit of time for this (at least a man year if you’ve not done
one before). There are numerous interaction problems to solve.
The key insight is to remember - you are implementing a file system. Not a
filter. You own all the structures which are “reserved to the file system”
but at the same time you take responsibility for all the things that the FSD
would do. So if in doubt consult the FAT sources.
Your difficulty is that your lower edge API is a file system API. So
implementing a layered FSD combines the upper edge complexities of an FSD
with the lower edge complexities of a FSD Filter. After all that I think
I’d sooner do a layered FSD than a filter (so long as I was given the time).
- How should I handle SectionObjectPointer?
If you want to own the cache you need to put a SECTION_OBJECT_POINTER in
your FCB (SCB actually, but lets not quibble) and point all your FOs at it.
You then need to make sure that you call CcXXX (inside a _try/exept) at the
right time.
If you don’t want to handle caching just point it to the lower one (and then
you have a shadow file object filter). Its a good implementation strategy
to leave the SOP until you have the framework in place.
Similarly if you want to arbitrate sharing you need to have a SHARE_ACCESS
structure.
Some other hints.
-
The failure mechanism is dreadful - you are no longer on the stack when
the lower FSD complains that it doesn’t recognize the File Object and some
of the crashes can be very perplexing. This is the worst drawback of using
FltMgr for this sort of thing.
-
If you are doing network as well as local disk consider two separate
impementation efforts. at the level of detail you need to work the
behaviors are different enough to be significant.
Good luck
Rod Widdowson
Consulting Partner
Steading System Software LLP