抢先体验微软最新文件系统winfs

　　1．打开computer，进入defaultstore。

　　2．本想建个music的目录，但是却出现错误，后来才发现是因为winfs正处于测试中，无法命名其中的项。

　　3．将音乐文件拷到defaultstore的根目录下。

　　4．在start menu中打开music目录，点击左侧的recently added，出现刚才我新加进的几个音乐文件。

　　5．点击鼠标右键，选择view?detail，然后点击上方的genre?stack by genre，发现音乐文件以其音乐的类型（比如pop）分成几个item，点击item进去，可以浏览该类型的文件。

　　6．在左侧的filter by输入框中输入pop（注意，非音乐文件文件的名字），凡是pop类型的音乐文件都显示出来，而非该类型的音乐文件都被隐藏。

　　7．将一些图片放入defaultstore中，在start menu中打开photos and videos目录，在filter by处输入1024*768，发现大小是1024*768的图片都被显示出来。

　　用到这里，感觉winfs好象没什么，只是作为一个文件的meta data的搜索器而已。但估计问题绝对不会象我所想的那么简单，所以便继续查找资料，追寻下去，发现了许多有趣的东西。

　　winfs是传统的文件系统以及关系数据库的延伸，它不仅存储以往的文件类型数据，也可以存储非文件类型的数据，比如一些个人信息、日程表、邮件等等。因此，在winfs中存储的单位不应该用文件来描述，准确说来应该是item。

　　首先要弄清楚几个概念：types/subtypes、properties/fields、constraints、relationships。

　　一．types/subtypes

　　type和subtype与面向对象的类及子类的概念相象，winfs中存储的数据都是某种type的实例（instance），比如我们可以创建一个type为person的实例，这个实例拥有自己的属性，姓、名、年龄、性别等等。每种type都会有自己的属性，即properties/fields。每种type都会有自己的超类型（super type）和子类型（subtype），与java等语言类似，一个type只能继承自一个超类型，但可以有多个子类型。比如contact和document的超类型都是item，而contact的子类型有person、group和organization等等，document的子类型有image和media等等，image的子类型有photo等等。winfs中预定义了几种“windows type“，比如person、message、document和folder等等。type可以被扩展，即允许用户定义自己的type，但是现在在这个版本的winfs中还不提供这种自定义功能。

　　二．properties/fields

　　properties/fields与类的属性的概念相似，每一个属性可以是一个标量，也可以是一个与c/c++的structure相似的结构。对于一个类型来说，可以拥有多个相同的属性，比如一个person可以拥有多个address属性。

　　三．constraints

　　对于每个propertie/field，都可以有约束（constraints），比如年龄必须是在什么范围内，姓名不允许为空等。但是当前发布的winfs版本还不提供对约束的支持。

　　四．relationships

　　在winfs中，type之间可以有关联（relationship），relationship创建在源类型的实例及目的类型的实例之间（源实例与目的实例可否是同一类型？）。源类型的实例是不可缺少的，一旦发现源类型的实例不存在，relationship会立即被删除。但是目的类型的实例却可以缺少，这种缺少目的类型的实例的relationship被称为“dangling relationship“。

　　对于一个relationship来说，它也可以与type那样拥有自己的properties/fields。举个例子，比如一个contact与一个message之间存在一个participant的关系，而这个关系可以有一个nickname的属性。

　　在winfs中，有两种relationship，一种叫holding relationship，一种叫reference relationship。

　　在这种关系中，几个源实例可以拥有同一个目的实例，只要还有源实例存在，关系就存在。其还具有以下几个特点：

　　（1）每一个实例都必须要有一个以上的holding relationship指向它；

　　（2）具有holding relationship的实例间必须是处于同一个store中。（对于一个winfs的item来说，它完整的unc名空间的形式是"\\machine\store\share\folder1\folder2\...\foldern\item"）；

　　（3）源实例和目的实例必须同时存在，不能允许dangling relationship的存在。

　　（4）实例间的关系不能形成回路，构成一个有向非循环图（directed acyclic graph，dag）。

　　（5）holding relationship采用层次式的命名空间（如上所示），每一个这样的relationship都会指明目标实例的名称，而每一个拥有这种relationship的源实例的名字则必须唯一。

　　2．reference relationship

　　在这种关系中，可以允许存在dangling relationship，可以允许实例分布在同一个store或者不同的store中，实例间的关系可以形成回路。比如一个document类型的实例用一个author的关系指向一个contact类型的实例，而这个contact类型的实例也可以用一个reviewer的关系指向document类型的实例。

　　以上说的都是一些很理论性的东西，这时会想，以上说的内容是通过怎样的形式表现出来呢？在操作上，在编程上。

　　在defaultstore目录下有一个schemas的目录，发现里面是一些item，比如audio、contact、mail等等，与上面所说的type的名称相对应。再翻阅资料，发现winfs有专门的基于xml语法的schemas definition language。比如contact类型有contact.xml作为其类型定义。而person的定义为

<type name="person" majorversion="1" minorversion="0"
　　　　 extendstype="core.contact" extendsversion="1">
<field name="birthdate" type="winfstypes.datetime"
　　　　 nullable="true" typemajorversion="1"></field>
　　<field name="personalnames" type="contact.fullname"
　　　　　　 nullable="true" multivalued="true"
　　　　　　 typemajorversion="1"></field>
　　<field name="personaladdresses" type="core.address"
　　　　 nullable="true" multivalued="true"
　　　　 typemajorversion="1"></field>
　　<field name="personalpicture" type="base.link" nullable="true"
　　　　 typemajorversion="1"></field>
　　　　 ...
</type>

　　可惜，在这个目录下的item都是0字节的无扩展名的，不知道到底是什么的东西，不象schema文件。用搜索查找contact.xml文件也查找不到。找了一些与winfs相关的程序，有纯 c# 的，也有使用了avalon的，然后用msbuilding编译。程序编译成功，但是运行出错。即使是创建新item、更改item属性这类简单的程序也不能运行成功。看来这个版本的longhorn中的winfs还有许多的限制。

　　玩了两天的winfs，本来是计划再琢磨多一些关于longhorg的东西，比如indigo，avalon编程和语音识别等等。即使是winfs，也有一大堆的内容可以深究，比如它的storage engine、security、synchronization等等。但是发现现在发布的这个版本的longhorn实在太多限制，所发布的资料中的许多特点尚不支持，而且未来肯定会有很多的变数，便决定暂且把这新奇的玩意放到一边，静观其变。其实，longhorn离我们还挺遥远，现在的硬件水平暂时也很难满足其需求。所以，对于我们这些普通人来说，了解其概貌及发展趋势便可，深究实是大可不必。