WinFS

WinFS (short for Windows File System or Windows Future Storage ) is a canceled storage subsystem that allowed users to search for items based on their metadata, regardless of the item's type of file and the application in which it was created. This in turn would make searching for content independent of format easier.

WinFS was billed as one of the pillars of Windows Longhorn. However, Microsoft announced on 27 August 2004 that WinFS would be in beta testing when Longhorn becomes available, and would be delivered after the Longhorn release. On 29 August 2005, Microsoft announced the release of WinFS Beta 1 for Windows XP Service Pack 2. A Beta 1 Refresh was released on December 2005. Regular beta and CTP releases were planned.

On 23 June 2006, Microsoft (through Quentin Clark, who ran the Program Management Team for WinFS) announced that there would no longer be a separate WinFS release. Instead, some of its parts were included in ADO.NET and Microsoft SQL Server.

WinFS was based on SQL Server 2005, ran on top of NTFS, and used metadata of files to improve organizing, searching and sharing of information. It also stored structured data such as contacts and calendars. WinFS replaced the traditional file system hierarchy of files and folders with items (either based on files or not, such as contacts and e-mails) and associations (relationships between items).

Development
WinFS is ultimately traceable to the Object File System (OFS), an integrated store, a data store, for storing document files, spreadsheets, multimedia files and other information which Microsoft planned to be part of Microsoft Cairo. The idea behind OFS "was to make sense out of all the bytes of data in the filesystem in a human readable and searchable way, organized as a collection of objects with properties all part of a strongly typed schema." OFS was a relational file system, "which would help manage local and distributed objects using an active storage paradigm" and "would have removed the need to understand where data resided", both locally and remotely. One build of Cairo, 1175.1, allowed OFS partitions (see screenshot). However, it is not clear if the features described for OFS are present. Instead, OFS, as implemented in build 1175.1, appeared to be a predecessor of the Content Indexer (now the Indexing Service) and Active Directory. BetaArchive user jimmsta explained:

Cairo fell apart in the mid-1990s. On March 1996, Microsoft said that work on OFS for a future release of Windows NT had been abandoned in favor of a file system based on its Exchange Server. The file system work was abandoned because of complexity, market forces and internal bickering.

BetaArchive user jimmsta theorized that OFS did ship, as the Active Directory File Store in Windows 2000. In his view, "the whole point of WinFS was to provide a localized version of Active Directory's file store".

The more common view is that OFS never shipped. Instead, new projects would perform its intended functions. One such project is Storage+, which Paul Thurrott said Microsoft would turn its attention to after Windows 2000 shipped. Storage+ which would replace the NTFS file system and with a relational, object-oriented file system based on SQL Server 8.0. The file system would become a relational database, speeding searches and providing a higher level of granularity for those searches Storage+ later became the Relational File System, which Microsoft intended to but failed to ship with SQL Server 2000.

Storage+ then became "a new SQL Server .NET-based file system". It was slated for Blackcomb, but by 2002, Thurrott reported that it would ship with Longhorn. CNET News.com reported:

Jim Allchin, the group vice president in charge of Windows development, said:

By 2003, Storage+ was called WinFS, would include technology from SQL Server "Yukon" (SQL Server 2005), and would not be a file system but a service on top of NTFS.

During PDC 2003, Bill Gates described WinFS as a "Holy Grail":

Bill Gates had earlier described OFS as a "Holy Grail" in his PDC 1996 keynote.

In his PDC 2003 presentation, Quentin Clark, director of program management, WinFS, explained the following points, summarized by Thurrott and Furman:

This WinFS schema diagram dates from PDC 2003.

On 19 April 2004, BusinessWeek reported that Microsoft would scale back WinFS to provide document indexing only on the local system and not over a network.

On 13 May 2004, it was reported that Bob Muglia, the senior vice president in charge of Windows server development told CNET News.com:

On 27 August 2004, Microsoft announced that WinFS would be in beta testing when Longhorn becomes available, and would be delivered after the Longhorn release. This meant that WinFS would be removed from Longhorn and would ship at a later date. Thurott wrote:

A report from 10 December 2004 quoted Muglia as saying that WinFS would neither be in Longhorn nor in Longhorn Server. Muglia also said:

He then described WinFS:

On 29 August 2005, Microsoft quietly made WinFS Beta 1 available to MSDN subscribers, but announced it officially through the WinFS Team Blog. Beta 1 required Windows XP Service Pack 2, and .NET Framework 2.0.50215.322. The WinFS API was included in the System.Storage namespace.

During PDC 2005, Microsoft released a video presentation, named "IWish", showing how applications would advantage of a unified type system. The concepts shown in the video ranged from applications using the relationships of items to dynamically offer filtering options to applications grouping multiple related data types and rendering them in a unified presentation. Steve De Mar, the Product Designer for the WinFS team, explained the goals of IWish:

In addition, during PDC 2005, Shishir Mehrota of WinFS Product Planning gave an overview of WinFS, Program Manager Ramesh Nagarajan gave a presentation on "“WinFS” Future Directions: Building Data-Centric Applications Using Windows Presentation Foundation “Avalon” and Windows Forms", (for which he built a simple Windows Presentation Foundation application that showed off how a richer document viewing experience could be built on top of WinFS) and Samuel Drucker, Development Manager, gave a presentation on WinFS and ADO.NET (on how ADO.NET is evolving to incorporate some of the WinFS aspects) and WinFS Programming with LINQ.

Four WinFS sessions were planned for Tech Ed 2006. Roger Lueder gave a talk on "Building on WinFS: Developing a Great WinFS App from Scratch".



Beta 2 was planned for some time later in 2006, and would have been integrated with Windows Desktop Search, so that the latter could display both WinFS and non-WinFS files.

But on 23 June 2006, Quentin Clark announced through the WinFS Team Blog, "With most of our effort now working towards productizing mature aspects of the WinFS project into SQL and ADO.NET, we do not need to deliver a separate WinFS offering."

Many of the principal features Microsoft intended to provide with WinFS included a pane for metadata property editing, breadcrumb-based property navigation, filtering or stacking items over properties, incremental search, and saved searches; these features were incorporated in Windows Vista. Query composition, a WinFS feature that allowed users to perform additional searches that reuse the results of a previous query, was later incorporated in Windows Vista.

Examples of uses of the technology are the object-relational mapping components into ADO.NET Entity Framework; support for unstructured data, adminless mode of operation, support for file system objects via the  data type, and hierarchical data in SQL Server 2008, then codenamed Katmai, as well as integration with Win32 APIs and Windows Shell and support for traversal of hierarchies by traversing relationships into later releases of Microsoft SQL Server and the synchronization components into Microsoft Sync Framework.

In 2013, Bill Gates cited WinFS as his greatest disappointment at Microsoft:

Limitations of traditional file systems
Traditional file systems, including NTFS which is used in modern versions of Microsoft Windows, store data only as a stream of bytes packed in a file. The Microsoft WinFS SDK Beta 1 Documentation explained the limitations of this approach:

As Richard Grimes explained:

Desktop search allowed a user to see different types of data from different sources. However, these data still resided on different sources, different places.

Traditional file systems also did not allow for storing files in multiple places without making duplicates. Hal Berenson, former General Manager of Integrated Storage (which would become WinFS after he left Microsoft), gave an example:

A solution is to put an external metadata later on top of the file system, and to use an application or library to interact with the photos instead of interacting directly with the file system. Berenson noted that this causes problems as applications typically won’t understand the layer and operate just on the file system underneath it. This can make functionality that the layer purports to provide unreliable (e.g., when the application changes something about the photo which is not accurately propagated back into the external metadata store). And with photos now stored in a data type-specific layer, it is ever more difficult to implement scenarios or applications in which photos are but one data type.

Berenson then illustrated the limitations of traditional file systems and the benefits of integrated storage by using the processing of claims against an insurance company as a scenario:

Lastly, Berenson noted that there is no way to back up and restore related structured (i.e., typical database data), semi-structured/unstructured data (e.g., a photo or document), and unstructured data, without a storage system that can be the primary store.

Grimes pointed out that one of the monumental problems organizations face is aggregating information that is stored in disparate formats. Knowledge workers have long wanted to be able to search for content independent of format. Sean Grimaldi of the WinFS team called the existence of many formats with different expectations and behaviors a "divide-and-conquer approach" in dealing with data. Grimaldi extensively discussed the negative effects of this approach and summarizes:

The Microsoft WinFS SDK Beta 1 Documentation described the existence of proprietary file formats as "separate islands":

Shawn Wildermuth pointed out what this system means for developers:

Using common file formats is a workaround to this problem but not a universal solution; there is no guarantee that all applications will use the format. Other solutions used by corporations are database systems and XML and XML web services, as Thomas Rizzo, director in the Microsoft SQL Server group, explained:

Traditional file systems also provide only a single way of organizing the files, namely via directories and file names. Vijay Bangaru of the WinFS team illustrated the problems with this:

A traditional file system can retrieve and search data based only on the directory path:

A user may put a file into multiple directories, but this wastes disk space. Also, when a copy is changed, the other copies no longer represent the same data as the changed copy. Hard links that can be created to represent a file by multiple paths are also difficult to manage: links will break when a file is renamed.

Bill Gates summarized all these issues in his keynote during PDC 2003:

Gates also stated in an interview from a month after PDC 2003:

WinFS as solution
The core concept of WinFS was that by storing data in a cohesive data store, not just a file system, it would have allowed systems and users to store rich metadata about a myriad of objects and to relate these objects. Compared to a file in a traditional file system, a "WinFS" item would be the smallest unit of data that could be moved around and operated on by different users or applications.

The Microsoft WinFS SDK Beta 1 Documentation explained that WinFS would have provided comprehensive object-relational mappings to let users view and work with their data as an item on a Windows computer. With items, a user or an application would have found it more logical or natural to view and use data. This should have made organizing and querying data, especially complex data, less burdensome. The documentation provided as an example:

WinFS would have served all kinds of data, whether structured (as in tables/rows or items), semi-structured (as in an XML file), or unstructured (as in a flat byte stream).

The Microsoft WinFS SDK Beta 1 Documentation and the IWish video summarized the benefits of WinFS integration into four points: Unify, Organize, Explore, and Innovate.

Unify
WinFS would have allowed data sharing between applications, as Grimaldi explained:

WinFS would have placed data from multiple applications into one central store. Bangaru showed the advantages of this:

Organize
Bangaru illustrated how data could be related, and how related data could be shown:

Explore
WinFS natively recognized different types of data by defining common item types, such as audio record, meeting, contact, person, document, photo, message, video clip. This would have solved the problem of querying the following data:

WinFS would have allowed queries such as "Show me all email from people I am meeting with this week," that NTFS could not.

Bangaru explained how one of the mockup applications showed in the IWish video would use WinFS:

Innovate
Bangaru explained how WinFS would have done away with proprietary file formats:

Drucker explained how WinFS addressed lock-in:

Synchronization is explained under Data sharing. Rules is explained under Rules.

Bangaru explained two levels of backup that WinFS would have included. Item level backup would have allowed a user to revert a change to an item. Store level backup would have covered the situation of a broken hard drive and a user needing all his files back.

Concepts
Hillel Cooperman explained in PDC 2003 in his demo of a build 4050 how WinFS would work in Longhorn:

WinFS was intended to have the following user interface (UI) features in Longhorn:

The storage model would have also come with the following elements:

Implementation
A Milestone 4 build that leaked in or around March 2003 contained "Windows Future Storage Services" and "Windows Storage Full-Text Index". A user opening Search would simply be asked: "What are you looking for?", with a list of example searches provided for reference such as "Pictures from John" or "What is a firewall?". The build came with libraries, stacks, and filter features.

WinFS Beta 1
On 29 August 2005, Vijau Bangaru, a Program Manager on the WinFS product team, announced the release of WinFS Beta 1 for Windows XP Service Pack 2.

The installer can be modified to allow WinFS to install on Windows Vista and Windows Server 2003:

Beta 1 Refresh was released to MSDN subscribers on 1 December 2005 to be compatible with the final release of .NET Framework 2.0.

Data storage

 * From this section, the discussion is on how WinFS worked under Beta 1, the latest release of WinFS to the public, not under any Longhorn pre-reset build. All documentation therefore should refer to the WinFS Beta 1 time frame, PDC 2005 included.

Architecture


WinFS used a subset of SQL Server 2005 technology, modified for file storage. It consisted of the following components:
 * "WinFS" Core - the core services expected from a file system, and included the relational storage engine;
 * Data model - the technical innovations of WinFS, including basic item structure, relationships, and the ability to extend both items and relationships;
 * Schemas - built-in schemas allowed WinFS to understand a user's data in richer ways than traditional file systems and provide a more structured way to handle metadata. Included were first, schemas for everyday information such as documents, e-mail, appointments, tasks, media, audio and video, and second, system schemas that define configuration, programs, and other system-related data;
 * Services - included syncronization and rules (discussed below);
 * APIs - which developers might have used to program the different building blocks of the "WinFS" system, including data operations, rules, synchronization, and the data model

WinFS required three services, which ran in three processes:


 * 1) WinFS.exe, the WinFS data store, that ran a Yukon (SQL Server 2005)-derived database engine
 * 2) WinFSSearch.exe, which ran the  WinFS search engine
 * 3) WinFPM.exe, which ran the WinFS File Promotion Manager. File promotion referred to the process of extracting data from a file and populating the data to an item. The reverse process of persisting itemized data to streams of the underlying file was called demotion. WinFS served all kinds of data: structured, semi-structured, or unstructured, through a new file system driver (RsFxDrv.sys). This driver allowed a user to access a WinFS item both as a file stream (as a file) through the Win32 API or as an item via the WinFS API. The process of file promotion and demotion kept the file-based and item-based representations of a WinFS item synced. This made WinFS backwards-compatible with NTFS.

WinFS depended on the .NET Framework, and used the same APIs as other data types thanks to ADO.NET. The WinFS API was included in the System.Storage namespace.

Data store


WinFS kept data in Stores, which in turn are kept in a relational backend. A WinFS store was a common repository where any application can store items and associations. Items could either be backed by files (for example, images and documents) or not (for example, contacts and e-mail). Associations established relationships between different types of data (items), which then allowed users to organize information based on how they used them. Bagnaru explained how items and associations were stored:

All data in the store were accessible as CLR objects, allowing a developer to leverage all their Visual Studio and .NET knowledge while building apps..

WinFS, by default, came with two stores, DefaultStore and Catalog. DefaultStore was the default location for user and application "WinFS" data. Catalog stored metadata about "WinFS" stores and shares, as well as other system data. The Catalog store was read-only and should not be used for user data. Users could create additional stores, but a store could not span multiple volumes and could only be hosted on NTFS volumes. The reason for these limitations was that every WinFS store had a root share with the same name as the store.

WinFS stores were made up of database files stored in a directory under the "System Volume Information" folder. Filestreams were saved as ordinary NTFS files with a GUID as file name. Tony Voellm of the WinFS Team explained, "The term NTFS Streams was used but the File Data is actually stored in NTFS files." Meanwhile, metadata is stored in a SQL Server database.

Data model
The WinFS data model is the architecture of the type system. WinFS introduced a type definition language, an XML vocabulary but not the XML Type Definition Language, to describe types.

WinFS provided a set of schemas that defined types and attributes for implementation by the WinFS API. A developer could also create custom schemas.

A schema was a collection of type declarations, such as the declaration of a postal address, a full name, or a person. Each schema defined a set of types that mapped to some information. All these types derived from a set of base types defined by "WinFS". The base types grouped related types together, creating type families.

The root types in the WinFS system were Item, Link, InlineType, and ItemFragment. The other WinFS types derived from the root types. Descendants of one of these types were entity types. For example, Person was derived from the Contact type, which derived from the Item type. AttachmentLink was derived from the Link type. Therefore, Person, Contact, and AttachmentLink were all entity types. An EntityType had its own unique identity, and so could exist on their own. In contrast, an InlineType did not have a unique identity and could exist on its own. FullName of a Person is an InlineType, a Person is an EntityType.

ItemFragments were also entity types, which enabled the declaration of large collections in the item types, such as multivalued properties. Each collection member had a key, which enabled applications to access individual members of the collection independently of the owning item. An example would be a message, which might have a large number of participants. The ItemFragment would be participants under the Item message.

Meanwhile, an EntityExtension allowed a user to extend built-in items by adding further properties as necessary. WinFS schemas defined several extension types. For example, the System.Storage schema namespace defined two ItemExtension types: Reminder (such as a birth date Reminder to a Person) and ItemKeywords (which allowed a user to assign keywords, such as "legal document" or "personal document" to a Document).

Links and associations
Links referred to data that defined links between two or more distinct existing item types; for example, an Item type, Message, might have attachments that were documents, another Item type. WinFS also provided the concept of Associations to relate items. Associations were not physically stored in the store. An example of an Association would be that declared by a user between the Document and Contact types when identifying the publisher of a document.

WinFS depended on applications and users to provide the information to create links. According to Bagnaru,

Item
The Item was the fundamental concept in "WinFS". An item was the smallest data element defined by WinFS, and was the equivalent of an object in object-oriented programming. Each item had a unique identifier, its GUID.



WinFS defined common item types, which resided in the following WinFS namespaces:
 * System.Storage.Audio
 * System.Storage.Calendar
 * System.Storage.Contacts
 * System.Storage.Documents
 * System.Storage.Image
 * System.Storage.Media
 * System.Storage.Messages
 * System.Storage.Video

An item that would fall under System.Storage.Documents would lead to, as Malik explained:

If a file did not fall under any of the common item types, WinFS stored them as a GenericFile item. This happened when no file metadata handler was registered for a file name extension. A file metadata handler promoted and demoted properties between structured file formats and "WinFS" items. (See for discussion of file promotion and demotion.)

A definition for item types then reduced the amount of code to bridge between types. Grimaldi showed the benefit of this:

Another benefit was common behaviors. Only one code would be necessary to save an item, regardless of type.

Defining common item types also allowed WinFS to look inside files in a similar manner to desktop search engines. Bagnaru pointed out:

Rules
WinFS Rules provided an object-oriented API useful in definition of data sets, logical properties of data, and associations between data items. . The WinFS SDK Beta 1 Documentation defined a rule as conditional logic used to define queries, filters, computed properties, or computed associations that can be composed, persisted, and reused.

WinFS Beta 1 supported the following rules:
 * FilterRule - A rule that contained filtering logic that could be applied to item(s) of the given type. FilterRules obtained derived item sets based on the conditions of the rule;
 * PropertyRule - A rule used to calculate custom properties from existing properties of data objects. For example, a PropertyRule could define a new property of the Contact class, named locale, based on the zip code of the contact's primary address. Property rules allowed a developer to define new properties on item types without modifying or extending the schema for that type. To illustrate, an email application could expose capabilities for creating a “Color” property for messages and allow each user to define the value of “Color” using their own logic;
 * AssociationRule: A rule to calculate relationships between data objects. For example, a Document could be associated with a Contact defined as its author or copyright owner;
 * ActionRule: A rule to identify actions available on various data types. Rules of this type identified actions to be performed on data items. For example, the Photo class could define resize or rotate actions;
 * Query: A rule that defined a derived set. It was used to implement execution of a query as distinguished from the definition of a rule.

Kati Dimitrova, a developer on the WinFS API team, explained how a query worked as a rule through a scenario involving Mary, a recruiter trying to manage and track candidates throughout her day across multiple applications:

Access control
Bagnaru explained how WinFS secured data:

Searches and queries
WinFS used OPath, a string-based query language used for filtering, sorting, and projecting information stored in the WinFS store. OPath was used in multiple places on StorageSearcher to specify queries, and in other places in the API, such as when creating StorageViews.

OPath allowed a user to perform the following types of queries:
 * Extent - Identified the source of the data queried in an OPath query expression;
 * Filter - Created a collection of objects that contained a filtered set of objects from the input collection;
 * FilterByType - Created a collection of objects that contained only the objects from the input collection that were of the specified type, or a sub-type of that type;
 * Group - Created a collection of objects that contained groupings of the data in a collection of objects;
 * Join - Created a collection of objects that contained parings of data from two or more input collections of objects.
 * Project - Created a collection of StorageRecord objects that contained only the selected properties of the objects in the input collection;
 * Sort - Created a collection of objects with the data sorted by one or more property values of the input collection;
 * Top - Created a collection of objects that contained the first number of objects in the collection specified;
 * TreatAsType - Created a collection of objects that contained objects that were converted to a base type
 * Union and UnionAll - Created a collection of objects that contained the data from two or more collections of objects;
 * Yield - Created a collection of values computed by applying the OPath expression specified to each object in the input collection

Notifications
A notification was simply defined as "TBD" in the WinFS SDK Beta 1 Documentation.

Data sharing and synchronization
WinFS Beta 1 included a Windows Shell namespace extension, which showed WinFS stores as top level objects in "My Computer". The stores also appeared as a share in "My Network Places". Files could be copied into and out of the stores. Applications could be directly used to save there through the share  in "My Network Places". Even folders such as My Documents could be redirected to a WinFS store.

WinFS Sync allowed synchronization of data between WinFS stores and non-WinFS, or external, data stores (for example, synchronizing contacts between a "WinFS" store and a PDA or synchronizing e-mail between "WinFS" and an e-mail server) and synchronization of data between "WinFS" stores (for instance, making "WinFS" data available on all computers in a home network or sharing a set of documents, peer-to-peer, at work).

WinFS Sync provided change enumeration services that used change tracking to determine all entities that had changed since a previous synchronization. It also provided change application services that made changes to the data in WinFS.

WinFS allowed for both one-way importers, moving data from an application to WinFS, and two-way importers, which allowed for both. WinFS could resolve conflicts among data. Neil Padgett, program manager working on the WinFS Synchronization APIs, explained:

Applications
WinFS Beta 1 shipped with unsupported applications: File System Sync Adapter, Microsoft Rave, StoreSpy, Type Browser, and OPather.

File System Sync Adapter
The File System Sync Adapter synchronized file-backed items and directories between a WinFS replica and a file system directory.

Microsoft Rave


Microsoft Rave allowed synchronization of two or more WinFS stores. A user could synchronize between WinFS folders in the same machine or in multiple computers, and also with other users in a Windows domain.

Microsoft Rave used peer-to-peer technology to communicate and transfer data.

StoreSpy


StoreSpy allowed a user to search for files in stores by executing queries. It supported type-specific grid views, reminiscent of Outlook 2003, for Documents, Messages, Events, Contacts, and Photos, with a typed preview pane for messages, meetings, contacts, and photos, and a debug preview pane for other types.

StoreSpy supported property, query, full-text, and folder based filtering. It also allowed saving and retrieving queries. It also included a one-way Outlook sync adapter to bring items from Outlook 2003. However, it could only read from a Global Access List.

StoreSpy did not allow editing of items or their properties, though it was slated for inclusion in a future release. WinFS was cancelled before it could materialize.

Shishir Mehrotra demoed StoreSpy on a video uploaded on the Microsoft Developer Network's Channel 9.

An earlier version, v0.8, was released for the WinHEC 2004 Longhorn build, 4074. It was an Explorer-like tool to browse WinFS, and allowed a user to inspect Item, Relationship (all 3 types), Extension, Nested Element, and MultiSet properties. . However, BetaArchive user ATeamInc found that the download link has not been archived.

WinFS Type Browser
WinFS Type Browser could be used to visualize WinFS schema types (not WinFS data which StoreSpy showed), their type hierarchy, methods, properties, other types it was related to, among others.

Shishir Mehrotra also demoed the WinFS Type Browser on a Channel 9 video.

OPather
WinFS Beta 1 also included OPather. Luiz Miranda of the WinFS Team explained:

Project "Orange"
Microsoft launched a team, codenamed Project Orange to build an application built on the Windows Presentation Foundation ("Avalon"), that would demonstrate some of the ideas showed in the IWish video from PDC 2005. (discussed above at Development). Shishir Mehrotra of the WinFS Team shared some links to job postings and quoted some job descriptions covering positions at Project Orange.

However, since WinFS development went dark, the status of Project "Orange" is unknown.

BetaArchive forum

 * WinFS Beta Refresh on Vista/XP - Possible? Useful?
 * Question: Longhorn 4079 - WinFS Storage fold. in my computer - thread is about 4074; the post by Smartie77 explains how WinFS works in the build
 * Static List? - UI feature for Longhorn-era WinFS
 * 4015 playlist maker
 * Communication History in Longhorn
 * Original Patent for Longhorn
 * Breadcrumbs in Windows Vista Developer Story - Breadcrumbs were intended as a UI feature for Longhorn-era WinFS, see Development
 * Impact of release of WinFS on computing?
 * WinFS Beta 1 on any Vista post-reset build
 * Error accessing Global Address List when syncing Outlook with WinFS Beta 1 StoreSpy
 * Where does Longhorn 4074 WinFS store Outlook Express emails?
 * WinFS: A pillar of Windows Longhorn and Bill Gates' biggest disappointment

OFS

 * Plaintiff's Exhibit 5542 - Microsoft Windows Cairo Product Planning Product Requirements, evidence part of the Comes v. Microsoft case

Microsoft

 * WinFS: The Windows File System (Microsoft Access 2002 Technical Articles)
 * User Experience (Aero): Contacts (Microsoft Access 2002 Technical Articles)
 * The Pillars of Longhorn - from the Microsoft Developer Network (MSDN)
 * The Pillars of Longhorn: Living La Vida Longhorn (Longhorn Foghorn) (MSDN)
 * Chapter 4: Storage (MSDN)
 * WinFS Lets Users Search and Manage Files Based on Content | Microsoft Docs
 * Data Access and Storage Developer Center: Building WinFS Solutions - WinFS Longhorn era on MSDN
 * Wayback Machine list of all Longhorn era WinFS documentation archived from http://longhorn.msdn.microsoft.com/lhsdk/winfs/
 * Understanding Windows "Longhorn" - Official Microsoft links by Ian W from Neowin.net, includes Wayback Machine links for Microsoft resources on WinFS

Non-Microsoft

 * MS poised to switch Windows file systems with Blackcomb
 * XP successor Longhorn goes SQL, P2P – Microsoft leaks
 * Windows on a database – sliced and diced by BeOS vets
 * New Windows could solve age-old format puzzle--at a price, with timeline of Cairo's OFS
 * Get a Grip on Longhorn (Figure 5. List WinFS Contacts in a WinForm)
 * Microsoft geeft videopresentatie over WinFS - Microsoft provides video presentation about WinFS (Dutch) - Download page from the Wayback Machine of the video: MSDN TV: WinFS Overview - Significant New Storage Innovation
 * Code name: Longhorn by John Clyman, PC Mag article
 * Guide: WinFS and tasks in build 4042 | Microsoft Longhorn
 * Windows LGH 4051+WinFS - YouTube
 * Windows Longhorn 4074+WinFS - YouTube
 * An Opinion, blog by Mike Deem, Program Manager working on WinFS circa 2003, contains posts on WinFS

Reactions to WinFS delays

 * New file system has long road to Windows
 * More news on WinFS..., in response to "New file system has long road to Windows"
 * Shipping WinFS, in response to the links above ("New file system has long road to Windows" and "More news on WinFS..")
 * Proudly Serving My Corporate Masters: Scheduling and Black Hole Projects, connected to links above ("New file system has long road to Windows", "More news on WinFS..", and "Shipping WinFS")

Microsoft

 * WinFS Team Blog
 * WinFS on MSDN - WinFS Beta 1 era
 * Looks like WinFS is back on track
 * WinFS Beta 1 Released (video soon to come to Channel 9)
 * The WinFS Files: Divide et Impera

Non-Microsoft

 * WinFS Beta 1 and Microsoft’s Search Strategy
 * First Impressions: WinFS Beta 1
 * WinFS Beta 1 - The testing continues...
 * WinFS Beta 1: Useless?
 * WinFS Basics: Working with a Data Store
 * JD’s Weblog » WinFS Resources
 * Trends in Database Development: XML, .NET, WinFS
 * WinFS Overview - NTFS.com (first of a series, see Contents section)

Patents

 * US7590654B2 - Type definition language for defining content-index from a rich structured WinFS data type - Google Patents
 * US20060242167A1 - Object based test library for WinFS data model - Google Patents
 * US7502807B2 - Defining and extracting a flat list of search properties from a rich structured type - Google Patents


 * "winfs" - Google Patents

Hal Berenson: WinFS, Integrated/Unified Storage, and Microsoft

 * Part 1
 * Part 2
 * Part 3
 * Part 4

General links

 * Channel 9 Videos
 * WinFS Newsgroup
 * WinFS area on NetFXGuide.com
 * WinFS Forever- 2010 | SwimmingPool.Net (features intended for WinFS that made it to Windows Vista and 7)
 * What WinFS is all About | The NeoSmart Files

Other forums

 * The WinFS File System For Windows Longhorn: Faster & Smarter – OSnews
 * Longhorn build 4074 and default store
 * Using WinFS in Codename Longhorn 4074 : General Windows Support
 * WinFS Beta 1 Released Early - Slashdot
 * WinFS Beta 1: How useful? - AeroXperience
 * WinFS ready applications? - AeroXperience - 2,000 Members =)
 * AeroXperience -> WinFS (Older version)
 * News: Microsoft kills WinFS project
 * So what happened to WinFS? : General Windows Support
 * I need to un-install .NET2.0b : General Windows Support - Uninstalling WinFS also uninstalls the .NET Framework 2.0 beta
 * WinFS - what it could have been, and why it failed | MetaFilter
 * filesystems - What happened to WinFS? - Super User
 * Who Needs Git When You Got ZFS? (2013) | Hacker News, with discussion on WinFS