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?"
Well, if WinFS is default, million of users _will_ use it. They don't care or know what's in the bottom. They just use the system that came with the PC. Only the future will tell what this will do to your system,
after all we weekly encounter new and exciting ways spyware/viruse/worms/etc. screws up windows.
"What's your take?"
It's too fscking early to say.
Stop talking out your ass and speculate on something important, like Episode III.
Joe
http://www.joegrossberg.com
Security isn't my primary worry, at least at first. The indexing data is stored in an SQL database. I've had my share of registry corruption to know that when Microsoft stores a pile of critical information in a centralized database, you'd better keep that database backed up. At the very least, it'd be wise to stay away from the new formats until everyone else has debugged them.
This is America, damnit. Speak Spanish!
The programmers at Microsoft are surely aware of these sorts of issues. It might be a good idea to wait until the product is complete before deciding that it's terribly insecure.
And why on earth can't spyware do any harm if it doesn't have "root" privileges ? What's stopping it from popping up ads ? Or running a mass spamming process ? Deleting all files owned by you ?
Right now, all spyware has to do is a few simple registry entries to add itself to context menus, startup, Internet Explorer default search engine, etc. What's the difference between a simple reg tweak and a simple XML tweak? Same "exploits", just different interfaces.
I'm sure I'll be hearing from /. about how all the concepts in WinFS would be wonderful to have... just as soon as we hear something new about Reiser4. Seriously, just adding some extra metadata to a filesystem doesn't have to make it insecure; in fact, in Reiser4, they're doing it to make the filesystem *more* secure.
/.'er, but let's wait until WinFS is actually released to start picking it apart, ok? Until then, it's still vaporware, and there's no guarantee that it'll get released in 2005, 2006, or any other time.
Now, I know about MS' track record with security just as well as the next
And if it just ends up being a layer on top of NTFS that lets people sort their music and vacation pictures, well, I'm not too worried about it yet. And if it turns out that it's a security risk, then you *turn it off*, or just use FAT32.
pb Reply or e-mail; don't vaguely moderate.
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.
I know this could be a shock: Reiserfs4. go check yourself.
;)
How do we know which part of a 1gb file should lie in memory, and which should not?
it's not a filesystem matter.
It's just like a big database where we need good rules of what's good and what's not.
I, for one, hope that won't be microsoft to choose what's good or bad
Ummm..... .NET object.
Have you looked at the 2.4+ Linux Kernels. Or for that matter the BSDs or OSX, the fact is that UNIX and its workalikes are perfectly capeable of handling large disk I/O tasks. Especially with Journaling file systems like JFS or XFS, hell even ext3 does a decent job. This is annother example of Microsoft "innovating" in an attempt to beat a proven solution (EX. putting IIS into the Win2003 kernel) The fact remains that a good journaling filesystem, with a swap partition, more than likely is a much safer solution to the problem you describe than turning every thing on the disk into an XML taged
Did Glenn Beck rape and kill a girl in 1990? gb1990.com
Solution:
You will not have a choice.
Conformity is the jailer of freedom and enemy of growth. -JFK
What do we do now to protect our computer from spyware? Regularly update and run adaware. What will we do with WinFS? Regularly update and run adaware longhorn. No problem. I haven't had spy/adware in freaking years; of course, it helps that I've switched to a superior browser...
Condemnant quod non intellegunt.
The scary thing about WinFS will be the patent protection.
We've seen too many patents granted for which there certainly appears to be prior art. Someone else brought up the moniker, "Object Oriented Filesystems," and danced around the concept of single-level-store. That stuff goes back to the old IBM System/38, whose patents have probably expired. (It actually goes back further, but S/38 made it out the door.)
As others have said, metadata has been on the Apple resource fork since 1984, and OS/2's HPFS had Extended Attributes (OS/2 even had Extended Attributes kludged onto FAT.) prior to 1990. Then you (and others) bring up Reiser4.
I wonder what the patent filings on WinFS will look like. Reiser4 is obviously "published", but it would be good if there were some way to make the USPTO aware.
The living have better things to do than to continue hating the dead.
Windows is braindead and inconsistent in this respect. Much software still wants to piss in it's Program Files directory and will refuse to run unless it is run as Administrator.. other programs require it because of sloppy coding.
You'd think you could set everything in the Program Files directory to be writable by Admin only, but it doesn't work because of this.
Also, when you install software, it is unpredictable as to what it will do; whether it will put it's icons in the All Users start menu or in the current user's one.
So, basically, all there is to do is run as Administrator.. the system is nearly unusable otherwise.
Why? Because using normal files is just too slow. E.g. How do we know which part of a 1gb file should lie in memory, and which should not?
Actually, for interactive cases this is easier on Linux/Unix than on Windows because of the structure of the *nix inode. It allows for very easy random access of a file, so, like the other example, you can scroll randomly about your 1 gig file in vim without much worry. NTFS, FAT, and FAT32, on the other hand, are good for sequential access (great if you're copying one file to another, I suppose), but it's more difficult to page the file in memory, which, also aforementioned, is not the duty of the filesystem.
"For traditional file-based data, such as text documents, audio tracks, and video clips, WinFS is the new Windows file system. Typically, you will store the main data of a file, the file stream, as a file on an NTFS volume. However, whenever you call an API that changes or adds items with NTFS file stream parts, WinFS extracts the metadata from the stream and adds the metadata to the WinFS store. This metadata describes information about the stream, such as its path, plus any information that WinFS can extract from the stream. Depending on file contents, this metadata can be the author (of a document), the genre (of an audio file), keywords (from a PDF file), and more. WinFS synchronizes the NTFS-resident file stream and the WinFS-resident metadata. New Longhorn applications can also choose to store their file streams directly in WinFS. File streams can be accessed using the existing Win32 file system API or the new WinFS API."
So, it seems that the files themselves are still stored in a filesytem, it's only the metadata that is stored in "WinFS".
The data itself does *not* live as a blob in a giant database.
Nice, call people idiots based on your (most likely) incorrect interpretation of something you haven't seen, or (it seems) researched.
Even from the quick description you gave, it sounds pretty safe to me. Not modifying the underlying file system is IMHO a good idea and mitigates all the paranoia you are having.
.jpg should run a certain image viewer. This is not done in the file system it is instead done by another program that reads normal files and determines this information from the normal files. Now we all know that those file associations can be mucked with (ie hijacked to run another program) but in fact any such messing with it can be determined by a program reading the setup files, and easily avoided by a program using *less* code to run a program.
.jpg extension would be a real and unfixable disaster. But in fact they are avoiding this if your description is at all accurate. This is a *good* thing.
Windows already has the file associations like knowing that clicking a
Compare with a worst-case scenario where the system only had a "run this file" command and you could not determine what it did because it was encrypted into the file system (sort of what you really fear WinFS would do). Then somebody hijacking the
I do worry about some peoples intentions for meta data. In my opinion meta data should be used *only* as a "cache" of data that could be determined from the file itself. An obvious example is an image preview. But the file type and program should also be figured out using a program like the Unix "file" command and the result cached in the metadata. You could even make schemes by which the author, owner, permissions, date and time, and even filename are considered cached metadata and determined from the file contents. We should not have to rely on the correct transmission of anything other than the "data" bytes and the file length in order for a program using a file to do the correct and predictable thing.
I am worried that in fact most recent ideas in filesystems are going exactly the wrong way, and in fact Microsoft may be doing this right for a change.
Yeah, I agree with all that, but what I don't agree with is the people who claim this is *Microsoft's* fault.
I mean, hell, I could easily write an OS X program that tried to store all its data into a system directory and required an administrator account to run... would people suddenly declare that Apple screwed up, or that my program is crap?
Look at the software Microsoft writes: All of it is perfectly usable as a plain-jane user account, just as it should be. If other software developers wrote software *correctly*, the way Microsoft does, there'd be no problem at all.
So, in short, the parent post is true entirely... but it doesn't communicate how secure or insecure Microsoft products are because the problem is not *with* the Microsoft products.
Comment of the year
Look at this; It needs full read/write access to C:\Temp, C:\Winnt, C:\Winnt\System, (these ones are already wide-open in a default install), C:\Program Files\Office 97, and a bunch others.
This makes it basically impossible to secure a Windows box..
Let's see:
- It isn't slated for release until late 2005, early 2006.
- This suggests to me that what we're looking at in the current Longhorn builds is, in effect, early beta software.
- Microsoft have a long track record of changing their software quite dramatically through the creation process -- a la NT5.
- I don't particularly plan on upgrading to a Windows OS on my home systems if I can help it anyway. It'd have to have a hell of a lot of "must have" features before I'd consider doing so, since that would require an architectural switch for a lot of my equipment (Mac and Solaris to PC).
- At work, the IT department can bother with issues involving security/spyware and so on. Of course, the IT department's past history suggests we'll be upgrading to Windows XP about the time that Longhorn is finally released, and that any worms/virii won't be of much concern to them...
No, I don't think Microsoft will produce a particularly stable or reliable OS, or at least, not one which is much more stable or reliable than what they've released to date. Doubtless there'll be improvements, and doubtless there'll be new features to exploit. There always is, and I dare say always will be.Depending on file contents, this metadata can be the author (of a document), the genre (of an audio file), keywords (from a PDF file), and more.
This sounds exactly like the Desktop Database in Mac OS8/9, with a few extra fields.
Now, how is this new exactly?
You're just jealous because the voices only talk to me.