I am trying to do at file system level, what subst.exe does. From user
space point of view, I have 2 drive letters, let's call them C:
wish that every file access that references
, to go to another
directory on the C drive, like C:\foo.
\ -> C:\foo\
\bar -> C:\foo\bar
I wish to log every file I/O to D, and not log file access that is
done through C:\foo. When I mean `not log' I mean that I wish that my
logging filters won't run at all on the real volume, not that there's
some check in the filter that tells it to log only a specific
directory. That is, I wish my filters to reside only on D, and somehow
file I/O to be ultimately redirected to C:\foo.
I create a virtual volume (RamDisk) that gets a new drive letter and I
format it as NTFS. It's not used directly for file system operations,
I just create it so I can have something my filter driver can attach
to. I wish to implement a file system minifilter that does the
operations described above. From my understanding this can be done in
1) Filter IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE and associated
stuff, do the file I/O on the real target myself in the filter, copy
data to necessary buffers and complete the I/O in the filter. This is
very hard to do right, a lot of code to write, security is very
complicated (you can do in your filter anything, while you should do
only what the caller could do). I don't think I'll do this, I post it
here just for reference.
2) Filter only IRP_MJ_CREATE, modify the target paths and return
STATUS_REPARSE. This is easier to do and there is no need to think
about security (it just works right). However, the problem is that
since I return in the filter, and since I don't return the real stuff,
my logging filters attached to the virtual volume will either see
bogus stuff in the completion routine if the redirect filter is below
the logging filter, either nothing if it's above the filter. This is
3) Filter IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE and associated
stuff, the change FLT_IO_PARAMETER_BLOCK::TargetFileObject and
FLT_IO_PARAMETER_BLOCK::TargetInstance. I don't understand this yet.
It seems like I need another filter (same filter?) on the target
volume, which kind of defies the point of doing this, plus I am not
sure how it will interact with the logging stuff.
What (else) do you recommend?