Slashdot Mirror
WinFS - Who Will Actually Use It?
Hel Toupee asks: "Tom's Hardware is running an article about the file system to be employed in Windows Longhorn, the to-be-long-overdue successor to Windows XP. According to the information that the authors could get out of Microsoft, WinFS seems to be little more than an indexing and searching service that sits on top of NTFS or FAT. It is also very flexible and extendable, which, for Microsoft, can mean 'slow' and 'exploitable'. For instance: quite a bit of the inner workings of WinFS rely on XML data tags which can allow 'for instance, that developers will additionally be able to automatically display or execute commands linked to items located by a specific search'. This seems to imply that the new generation of spyware only has to change a bit of XML and it can add entries to your context menus, or open webpages when you click on a file, or, since files can be grouped by content in 'virtual folders', spyware could effectively add entries to these folders, or reorganize your entire filesystem on the fly -- all with slight tweak in some XML file! Am I being paranoid? WinFS seems fairly insecure, and I will not be using it if given a choice. What's your take?"
In the HFS filesystem, a file has two forks, a data fork, that corresponds to the file data in Windows or Unix file-system, and a resource fork, that contained structured data, basically bits of data that had an attached id, name and type.
Resources were used to store all kinds of stuff. This was very convenient, as you could for instance store the window shape of a text document in the resource fork without affecting the content of the file (data fork). This was also used to store custom icons, text styling without actually affecting the data. You could even use it to embed fonts into word documents.
The trick is, the OS used resources extensively, an application typically had an empty data fork and lots of resources (icons, pictures, sounds, windows, dialogs), including 68K code segments.
One Macintosh virus, WDEF, used this mechanism to propagate. What the virus did, was add resource of type WDEF to the database file describing all the icons on the desktop. WDEF resources were window definition code. So when the Finder (file explorer) opened this database file for a given volume, the resource would get loaded and overloaded the default window drawing code, thus enabling the virus to execute and spread.