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?

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.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.ma.../13/63199.aspx
__________________________________________________________



"Aaron Oneal" <Aaron Oneal@discussions.microsoft.com> wrote in message
news:38B84EFB-CAFE-4EA5-B12C-08852D3C5706@microsoft.com...
>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?

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.

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.