The first step in writing a property handler is to consider what properties your file type supports. Property values are stored in the file stream, primarily to allow transportability. When the property values are stored in the file itself as they are in this system, then when a user copies that file to another machine, a pen-drive, another file system, or sends the file as an e-mail attachment, the properties travel with the file and never get out of sync or lost. Therefore, if the file format supports storage of extra information, it is best to store the properties in the file itself.
The next step is to determine which properties the file should provide. At first you might think that a limited set of properties should be adequate. An audio file could support only audio-related properties and stop there. However, that audio file could be a recording of a session of a court of law, archived by a law firm. In that case, the law firm would certainly want to associate other non-audio properties with this file, such as the case number. The provider of the audio file format cannot possibly determine all of the scenarios in which their format will ever be used. They should therefore consider allowing blanket storage of any arbitrary property supported by the property system.
The property system in Windows Vista is an open metadata system. A file format stores any property assigned to it and exposes that value when queried, regardless of whether of it is aware of its relevance or meaning. This allows third-party developers to attach extra properties to the file without requiring a change in the property handler associated with it. Open metadata is a very powerful concept. If your file format can store any property that it might receive, you should always consider supporting it. Later in this set of topics, we show you how to support open metadata for an XML-based file format.
At this point, it would be appropriate to say a few words about Microsoft Windows NT File System (NTFS) secondary streams. This technology was developed some time ago to support the persisting of extra information with the file through an alternate stream set at the file system layer. One might wonder why those secondary streams are not used as the main method to store properties—especially with open metadata support. The primary reason is the transportability of this extra information. Unfortunately, these alternate streams are removed in many scenarios including client-side caching support (CSC), sending files as attachments, and copying files to a non-NTFS store. Therefore, they do not provide a robust solution where the properties are guaranteed to travel with the file, so the Windows Vista property system does not provide a built-in mechanism that exploits the secondary NTFS streams for property storage. Independent software vendors (ISVs) are also highly discouraged from building property handlers that use secondary streams for the storage of properties. Of course there are scenarios where NTFS secondary streams are appropriate, particularly when applications can guarantee that the file they are dealing with is always stored in an NTFS volume and will not travel as a result of end user interaction.