This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: CLI326: WinFS - File System Integration and Security
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
WinFS is a marriage with NTFS! It's a file system that co-exists with and leverages
the best of NTFS. There are areas where NTFS will not scale well in the future, not
because as a file system it is inadequate but because the new requirements people
will have in a world of digital data requires a more relational, query-orientated
file system. WinFS is the solution to this problem.
Looking back at the evolution of Windows file systems, the jump between FAT and NTFS
was huge - everything from file layout to the algorithms for storage were completely
revamped. WinFS does not represent such a huge shift, however - it is based on the
same paradigms but offers stronger and deeper metadata support and a new querying
model.
Key WinFS Concepts The store is a top-level container for WinFS items. There is more than one
store per NTFS volume, and stores for the system volume are created by default. WinFS
effectively carves out a chunk of the C: drive (called the DefaultStore at present)
as a file; WinFS then exposes as individual files. When you install WinFS, a second
store called the CatalogStore is also created - this is a meta-store which contains
information about the other stores on your system. You can also create your own stores
on-demand against new or existing volumes. Manipulation of stores will be possible
through the standard disk tools such as Disk Management, Disk Fragmenter, as well
as new tools to do WinFS-specific operations such as consistency checking. WinFS will
also integrate into the Plug'n'Play infrastructure, so that as volumes are plugged
in, their stores are surfaced in the WinFS namespace. In summary, the ideal situation
is that WinFS is transparent to the end-user from an operating perspective.
Shares are a view that are carried forward into the WinFS world. WinFS shares can
be created to any folder within WinFS. Again, by default, Longhorn creates a share
called \\localhost\defaultstore, but
you can create your own shares deeper in the store (for example, \\localhost\sharedpictures).
You can then drill down deeper into those shares, e.g. \\localhost\defaultstore\contacts\tims.
What is the default behaviour of WinFS when you install Longhorn? WinFS is not a NTFS
replacement - as mentioned already, it is hosted within an NTFS volume. A fresh install
will host the Documents, Pictures, Music and Videos folders in the DefaultStore. For
upgrades, Longhorn will migrate this same content into the DefaultStore. For non-standard
directories, a tool will be provided to migrate this content into the store.
Developing for WinFS The ItemContext class can be used as a scoping object into the store. You
can use a ItemSearcher to query against an ItemContext, optionally using OPath filters.
Once you have found a document, you can create a standard StreamWriter object as a
streaming interface into the file.
The traditional Win32 API calls are also supported natively in WinFS - for example
CreateFile, GetSecurity and so on. The same UNC namespace described above is common
to both the managed WinFS API and the Win32 API. One caveat is that non-file backed
items are not exposed via Win32.
Every WinFS application starts with an XML schema which defines the types and relationships.
Within this schema, a PromotionData section (containing PropertyMapping elements)
allows Longhorn to promote custom properties from OLE Document, coupled with
DocumentMapping elements to define which document extensions are to be included within
the schema. This allows applications like Word to be able to build and expose WinFS
metadata without having to have any knowledge of Longhorn or WinFS.
Demotion is the opposite of promotion. Demotion is the process of taking
metadata from WinFS items and moving it back into files so that legacy applications
which only understand files can continue to get at this information. For example,
if you edit a Word document custom property via the shell, it automatically gets updated
in the underlying file itself as a result of demotion.
Security A WinFS item is the lowest level of granularity for security control. Every
item has a security descriptor, containing a discretionary ACL and a security ACL.
As with NTFS, there is an inheritance mechanism that allows objects or containers
to base their ACLs on a parent object. Inheritance can be blocked so that it does
not propagate through the hierarchy.
WinFS Event Handlers Every update to WinFS can be processed by an event handler before updating
the store. In concept these closely resemble a SQL trigger. You can register your
own event handlers (for example, an anti-virus software vendor might scan a file before
it is updated). Event handlers can reject, accept, add to or replace an operation,
and can accept just a subset of operations rather than having to monitor every item.
It wasn't clear from the session how the order of event handlers is managed - will
every extension attempt to make itself the last event handler? There are however mechanisms
to prevent a virus itself from registering itself as the final event handler.
Previous Topic
