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.
