Vista - Filter Driver and NTFS Location of File Backed Items

I am interested in writing a filter driver to monitor file open and close
operations within the WinFS store. Is there a new way to do that in WinFS or
can I simply piggyback on the existing NTFS methodologies? If so, where
exactly are the file backed NTFS streams stored for a particular store or
volume so that I know which locations to monitor? Have I understood correctly
that a file backed Item can point to a stream on the local disk "C:\Documents
and Setings\..." but could just as likely be stored in a WinFS managed stream
location like when copying a file into a store using the WinFS namespace
extension?

Well, I found the answer to my question. FileBacked item data is currently
stored here:

C:\System Volume Information\WinFS

So, I assume my filter driver should be able to monitor that location and do
what it needs to do.

"Aaron Oneal" wrote:

> That's not really what I had in mind, I don't believe WinFS Rules can satisfy
> this. I am interested in the following:
> 1) Is a file stream being opened, and if so, can I deny access to it?
> 2) Is a file stream being written to, and if so, what location, how many
> bytes, and with what data?
> 3) Is a file stream being closed?
> 4) What is the real NTFS location of a file backed item? -- Not the
> redirected location provided by RsFxDrv.sys.
>
> From my own research, I understand I can write a normal filter driver on the
> redirected location to find out points 1 through 3, but what I'm missing is
> point 4, the ability to tie the redirected WinFS location back to the
> original NTFS file.
>
> Part of what I need to understand is whether or not file backed WinFS files
> are always copied and internalized in the WinFS store or if they can continue
> to exist in a non-WinFS manged location as well.
>
> Specifically, if I have a file called C:\Readme.txt and I add it to a WinFS
> store, can I continue to modify the file from the C:\ and have the updates
> automatically be promoted into WinFS? Or does it instead copy the stream
> when I add it to WinFS, and from then on, they exist as two separate and
> disconnected file streams? At least with Beta 1, it seems the latter is true
> and that there is no way to create an Item in WinFS with a paired backing
> file on a regular NTFS volume.
>
> Personally, I would prefer it work that way as it saves me the trouble of
> worrying about monitoring both the true backing file location and the
> redirected location of RsFxDrv.sys on content that I need to manage. The
> only thing that has led me to believe it might work otherwise is the numerous
> posts I've found around the Internet that seem to give examples of WinFS file
> backed Items pointing to standard NTFS volume locations. There seems to be a
> lot of misinformation out there about how that binding works.
>
> Whether the streams are copied and internalized or not, I'd still like to
> know where WinFS is storing all of these streams so I know how to back up my
> WinFS repository on the volume. I suspect it's just storing them within the
> SQL Server databases along with the Item info at
> c:\windows\system32\winfs\data and then RsFxDrv.sys is providing two mappings
> -- a namespace mapping which maps FolderItem NamespaceNames to provide the
> UNC access we're familiar with as well as a second internal mapping which
> provides lookup to the real stream using the ItemId namespace.
>
> Can anyone provide more clarity or point me to some reference materials
> about the internals of what's going on here?
>
>
> "Sahil Malik [MVP C#]" wrote:
>
> > The File Backed items are made possible using RsFxDrv.sys. Yes there is a
> > new way of doing what you are suggesting in WinFS - please check out "WinFS
> > Rules" (Literally it does). There may even be a generic way of detecting
> > only changes - I'm not familiar with that though.