Slashdot Mirror
Next Windows to Have New Filesystem
ocipio writes: "Microsoft is currently planning a new filesystem. Its planned that the new filesystem will make searches easier, faster, and more reliable. Windows will also be less likely to break, and easier to fix when it does. The new technology will cause practically all Microsoft products to be rewritten to take advantage of it. Called Object File System, OFS will be found in the next major Windows release, codenamed Longhorn. More information can be found here at CNET."
Rather a good thing to know.
dinner: it's what's for beer
Yes, you are a troll. Is it wrong for Microsoft to advance File systems and state specific reasons and right to preach about the many choices in file systems linux/unix has?
When your talking
Say when you open a folder of 5,000+ mp3's and it searches the ID3 tags of every song and displays artist/title as part of the description, having an optimized file system for quicker searches of data on the disk will only streamline this more.
so yes, this is cool, and yes, there is alot more then just "fast searches" as you put it.
Hey trollie, read the article. Or better yet, the Slashdot posting. This file system has nothing to do with DRM.
.. boy, don't even get me started on that.
Firstly, there is no such thing as "Microsoft Digital Rights Management Software" (Media Player supports DRM, but only for WMA's) and Microsoft has nothing what-so-ever to gain from including DRM features into the file system. They know and we know that Longhorn with DRM will go down the toilet, while Longhorn without DRM will sell just as well as WinXP, probably better.
The second thing you got wrong is that this system is not (just) about speeding up searches. It's about replacing an antiquated system that's been around since MS-DOS with something future-proof, faster, and more reliable. Considering they've been working on this for 10+ years, they'll probably succeed eventually. And when they do
Now, for something constructive. When will we see this in Linux? Surely, if Microsoft can do this, so can the people working on Linux. Riiight?
Quality, performance, value; you get only two, and you don't always get to pick.
The Register had and article about this ages ago.
Think SQL Server 2003 = OFS
Not only do they get their new FS with nifty new features (DRM yada...yada...) but imagine this scenario...
MS Sales Rep: "You need a database?"
Potential Sucker^H^H^H^H^H^HCustomer: "We're looking at Oracle."
Rep: "Oracle's OK and all, but you know...the TCO is over the top. With Windows NG [Next Generation], a top-notch, state-of-the-art DB is included for free."
Customer: "Really? Hmm...well, if it's already in there, I might as well use it."
Don't knock it, it worked with IE.
Getting rid of extensions is not necessarily a good thing...
.avi files. Of course she checked a and then w and then mi* area and no guesses were right. The right answer was "Movie Clip" (way to generic, but anyway...) Now look at the same dialog under, say XP. You will see that things are sorted by extension. While it may seem clunky and inelegant conceptually, in practice it is elegant. I would say identifying type is important enough to belong in the filename.
/etc/magic would be prohibitively slow. If you suddenly designate a part of the file space as needing to contain type information, tons of legacy problems can arise, and that field better be pretty long, and have a standard organization dictating what gets to use what codes. You can keep the information out of the file and efficient through Extended Attributes (already possible with NTFS, XFS, Be's FS, among others), but as I mentioned before this would not work cross-platform.
First off, all kinds of things are already designed around the extension idea, redesigning everything won't work that easily. Also, users are used to the concept of extensions. MS is very much aware of this. If you take, say, Windows 98 and go to edit file type associations, the list is sorted by type description. This doesn't work, as the user is not likely to know the string attributed to the file type he is thinking of. For example, recently my fiancee wanted to change the default viewer for
Secondly, these extended attributes are not portable. Many widely used protocols would be unable to automatically notify client machine of this information, forcing the user on every file downloaded to set the type of the file manually. Sure you can embed them directly in the file, but who gets to dictate the format? I can bet you that MS would extend any standard to break compatibility with other systems if it existed. By tying in the reading of these extended attributes more tightly with the opening of files, you are inviting MS to come and make life harder on non-MS platforms, as well as technologies such as DRM to have more success...
Finally, what about performance? As it stands, a system based on
The system as it stands now works quite well. Windows explorer already works to "protect the user from himself" by not allowing renaming of extension on a file easily. We have an established, cross-platform standard for identifying file types, we don't need to blow that...
XML is like violence. If it doesn't solve the problem, use more.
That's what they said about the registry. It will solve all of the problems with ini files.
But as everyone knows, with totally undisaplined usage of the registry, the registry is a nightmare. In some cases it is impossible to clean it up and the only solution is a reinstall.
Ask any dba. Even with the most heavy duty industrial strength db, somebody can come up with a schema and application that will bring that db to its knees. Prepare for deja vu.