Next Windows to Have New Filesystem 1008
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."
Predictions (Score:3, Insightful)
Yes, I'm cynical. But really, why shouldn't I?
:Peter
Can you say DRM? (Score:3, Insightful)
To be honest, NTFS seems to be a tip-top file system to me. The only thing I can imgaine it missing is hardcore digital rights management (cant wait).
What a clever way to force DRM down every consumers throat: break every single windows program created prior to OFS.
fuckers.
I could be wrong but... (Score:2, Insightful)
Haven't we heard this before ? (Score:2, Insightful)
Windows will also be less likely to break, and easier to fix when it does.
Doesn't MS say this about all the new versions of thier products ? Not that Windows hasn't improved, it certainly has, but they also never seem to live up to the hype.
Wow! This would mean (Score:4, Insightful)
I'll pass. I may be running (pre-installed) XP on my Dell but I'm still using Office 97. Why?
BECAUSE IT WORKS JUST FINE.
I don't need to "upgrade" to something even more bloated and bug ridden.
My question (Score:3, Insightful)
Re:More "security by obscurity" no doubt (Score:3, Insightful)
No built-in copy protection? (Score:5, Insightful)
Rather a good thing to know.
Re:OT: Refreshing! (Score:3, Insightful)
XP is an NT-based OS...why were you using FAT32 at all when NTFS is available?
C-X C-S
Re:You realize why they are doing this...right? (Score:5, Insightful)
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.
Re:The rift finally breaks wide open (Score:3, Insightful)
If only Windows Scripting Host gave you a more dead-easy way to script/tinker with the Windows objects...
Re:You realize why they are doing this...right? (Score:5, Insightful)
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?
How do you figure? (Score:3, Insightful)
Ummm...Why?
Changing the FS would really only affect the way the data is stored on the drive, the AppFS interface should be abstracted by the OS.
C-X C-S
Re:Veritas? (Score:3, Insightful)
The rough idea I got was that they want to make the file system a giant database, though. This would be a vast departure from NTFS, FAT32, or any other file system used today. They're saying "instead of creating database files on a hard drive, each for a specific application - and then creating all of these independent files and folders for the applications themselves, why not dump *everything* into one large database that *is* the file system?"
I would think that they wouldn't *have* to rewrite apps like Office in this scenario, but they'd *want* to - to take advantage of the new functionality possible with such a "database as filesystem" concept. Without a code rewrite, the Office apps wouldn't be able to import content via advanced search features. (EG. Import all photos on my drive related to the company I'm writing my letter to, above, and let me browse these thumbnails so I can find the ones I need.)
Try Again. (Score:2, Insightful)
Thank IBM, DB is the way to go for FS (Score:3, Insightful)
I'm personally glad MS is finally changing their OS. Now that my workstation has 70GB of files, searches are taking an incredibly long time.
I have less than 100,000 files on my workstation. Each has maybe 10 searchable attributes. A full search on this can take over five minutes. (Athlon 800Mhz w/ 7200 RPM IBM drives on a Promise controller)
I know from experience that querying an Oracle database (on a cheap 500mhz linux box) on 100,000 records with 30 non-indexed columns/attributes generally takes around 2-3 seconds.
Imagine if MS were able to build a file system with such capabilities.
Re:As long as they get rid of file extensions... (Score:3, Insightful)
right click on pretty much any file (win2k), select the summary tab, click advanced, fill in the author and revision number.
Many executable files also contain pre-filled version numbers on the version tab: \WINNT\explorer.exe has company name, internal name, language, original filename, product name and product version as well as file version, description and copyright notice.
But, yes, windows does still rely heavily on file extensions to determine type/opener. I don't mind that so much. It's easy to change a file from one format to another by changing its extension. It's I've had trouble with files on the mac that are bonafide jpegs, opening in simpletext (I didn't have PC exchange set up properly, and the file types werent set to PHSD (or whatever the magic number for photoshop is)).
Re:They just discovered... (Score:4, Insightful)
Right. This begs the question of why bother ?
The push et al is just a load of hype to push the upgrade path. They are going to engineer a database into their file system "to make searches faster" because doing it the slocate way would not force another round of complete system upgrades on consumers.
You may have also noticed that Outlook and Office will need to be rewritten to "take advantage" of the new file system. So not only will they leverage OS upgrades, but Office upgrades as well. They are planning to rip out a perfectly good file system (which is called "antiquated" in the article) to make billions of dollars, and the press releases are all about consumer benefit.
And consumer benefit, as you have noted, is essentially nil.
C: (Score:1, Insightful)
Yawn. It's been done before (Score:2, Insightful)
Re:Predictions (Score:5, Insightful)
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.
Re:As long as they get rid of file extensions... (Score:5, Insightful)
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...
Re:OT: Refreshing! (Score:3, Insightful)
Look at it this way - some of us may wish that the whole world used Linux, but it doesn't. It uses Windows. So when MS announces that they're taking a big risk (and it is a big risk) to try and make such an enormous upgrade to Windows, I think we should be happy that a few years down the road, if Windows is still dominant then at least people will be benefiting from this technology.
But ... this doesn't mean we should just sit back and go - well done Microsoft! After all, I recall reading about something similar over at the reiserFS page... how long until Linux users get this technology also?
Re:OT: Refreshing! (Score:2, Insightful)
Registry Redux (Score:5, Insightful)
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.
Re:Searching by content (Score:2, Insightful)
One of Unix's greatest strengths is the widespread use of human-readable files.
+ Do man pages use bizarre binary formats for markup? No, some inscruitable codes are there, but the text of the man page remains.
+ Are configuration files kept in a common, fragile binary repository? No, they are stored as human-readable, editable and searchable files.
Why does Microsoft want to change their filesystem? Well, they are now getting bitten in the butt for having binary file formats, and want to fix the problem by making yet more proprietary layers, locking out other search solutions.
Re:Predictions (Score:2, Insightful)
1)it doesn't matter if its illegal for alot of people... downloading mp3s is illegal, using decss based dvd players (i believe ogle???) is illegal, things like that. Once the code is out there, if someone has a use for it, they'll use it.
2)I doubt this will be an issue. By the time longhorn comes out, things probably will be very different in the tech world as they always are for every new windows release. If the aol stuff happens, Microsofts control will slip alittle. If thats the case they won't be able to force upgrades as easy as they did with xp which means they won't get as much software tailored for the new fs, which again hurts the chances of people upgrading. Microsoft should stick to what it has, 20 years of backwards compatibility. If they really wanted to make a drastic change, they should of done away with the 9x line long long ago (like around 95) and stuck with nt and fixed that. Starting fresh is only going to hurt them, especially when their application base is their greatest avantage.
but will it have symbolic links? (Score:2, Insightful)
Don't tell me short cuts are equivalent to symlinks. They are a veneer on top of the OS. They are not transparent as symlinks are on UNIX to programs that don't know about symlinks.
Re:I could be wrong but... (Score:2, Insightful)
Sounds like xml docs with formatting appendages (streams) would be a bit easier.
I guess Bill would lose his Office monopoly tho, if that were the case.
Nevermind
Re:Wow! This would mean (Score:3, Insightful)
Genius.
Re:Wow! This would mean (Score:4, Insightful)
If Microsoft ships the OS with HALF of the OFFICE CODE already EMBEDDED in SYSTEM DLLs, you still can't USE OFFICE without the other HALF...which is what you installed when you loaded Office XP.
That's why it LOADS faster, RUNS faster, and has SMALLER executables. The code for office, much like every other Microsoft product is being MIGRATED into the OS itself.
The OFS initiative will EMBED SQL Server INTO the OS itself.
Bye bye RDMBS competition.
Got a browser competing with you, embed IE into the OS. Got Citrix competing with you, embed terminal services into the OS. Got Oracle competing with you, embed the DB.
It's a proven successful tack and it makes sense.
Re:Predictions (Score:3, Insightful)
Re:Metadata (Score:3, Insightful)
Microsoft is proposing just such a scheme-- they will control the filesystem. If applications access the filesystem through the proper API/system calls the OS can ensure that the file metadata will be kept in sync. (I.e. they will have required arguments to the API to provide input for the metadata.)
To take one of your questions as an example:
Suppose there is a metadata field for "last accessed time". The HTTP server opens the file for reading using a fictional Windows system call called "open(*FILE)". Windows then internally updates the "last accessed time" metadata field and opens the file for reading. In this simple case the OS does all the work.Suppose there is a new metadata field for "last accessed from ". In this case the "open(*FILE)" call would need a new parameter (or some other way to pass in metadata like "open_new(*FILE, *metadata_struct)") so that the HTTP server can feed in the server that accessed the file. For backward compatibility the default might be the local server if the old system call/API is used.
Of course, this is all still vaporware. We'll just have to see what really happens.
Re:Predictions (Score:1, Insightful)
I remember the old BBS days where you could type something, and then backspace over it, and it would save everything you typed, the original, the backspaces, and the new text. So as you read, a word would slowly disappear, and then change.
This was sort of bad if you typed something you really didn't want people to see, but funny if you used it to call someone a name in jest, and cover it up with somthing more tactful.
So when you see ^H, just think they are backspacing over what they just typed. That's the joke. If you are used to using terminals, or old software, then you'd understand a little better.
Re:funky fat32 tip! (Score:4, Insightful)
Yes, I know you are not supposed to store things on the desktop, but windows makes it far too easy to do so. Plus it has the advantage that once you have downloaded a file, you can see it immediately without having to navigate to the right directory.
Re:Sigh... I really would like to see this in Linu (Score:1, Insightful)
Unfortunately most of the comments here are dissing on MS, or saying "use ASCII!" or some other lame cop-out. Yes, MS has an illegal monopoly, and yes they are horrible, yadda yadda yadda. That's not the point. We're so busy talking crap that no one stops to see the good ideas here, and how we could benefit on Linux.
The point (I think) is that this is useful. This is like Be's filesystem. I would love to have that under Linux. Or even, to merely have OS/2's extended attributes under Linux would be wonderful. THAT is what we should be discussing. Everything else is just noise.
I'm working on my own Linux-based OS (who isn't? *sigh* I try to keep it in perspective, though; I'm just doing this for me and family for now). I have no sacred cows, with regards to designing an OS. I would love to support a database-style filesystem. I would love to have metadata supported in the filesystem. I would love to have the entire user interface and all applications take advantage of this. But how? As a first step, could ReiserFS take plugins to allow metadata to be attached to files? Could Qt be extended to interface to that? Is there any general format that existing tools (tar) could use to not lose this metadata? As an example of how this could be useful, I take lots of pictures with a digital camera. I would like to annotate the images somehow. Embedding those annotations in HTML doesn't work because the annotations are lost when, for example, the image is emailed. (Yes, JPEG has a comment field, but what about the hundreds of other file formats out there that don't?) Think like a computer scientist--this is generally useful, so it should be generally available. Abstract it out; think of the jpeg comment field as a single hack; I want the full elegant solution. It should be in the filesystem.
MS's vision is larger than what I've said here, but even this would be a huge leap forward for Linux. I would like to see it happen.
I could go on and on... But most people would rather bitch about MS, rather than thinking how we can improve a free operating system. *Sigh*.
(If anyone wants to post more ideas rather than anti-MS rants, post below. Maybe we should get together on this.)
-Charles
Re:Predictions copy management (Score:3, Insightful)
An administrator (sysadmin, root, whatever) should never be denied access to anything ever, no way, no how, zip, zilch, nada.
Without full access to the machine, and every resource on it, it is impossible to properly administrate it.
"Permission Denied" shouldn't even exist for the administrator account.
Explain how this is a risk... (Score:3, Insightful)
I wonder how many R&D projects get canned in MS. Probably a whole lot. And considering building a new FS is nowhere near innovative. Are you suggesting that MS thought up the idea of this new type of FS? Puhleeze.
Re:Cross platform compatibility (Score:3, Insightful)
Now if we were talking about Microsoft coming out with a new obfuscated replacement for SMB (which is an evil hack and needs to be replaced with something less thoroughly bletcherous anyway), then you might have a point. But we're not talking about that at all.
Re:Is Linux too busy catching-up to innovate? (Score:2, Insightful)
Nothing's a risk when you have $billions in the bank. Do you realize how long Microsoft could coast at this point if they completely stopped doing any work at all?
Re:Is Linux too busy catching-up to innovate? (Score:4, Insightful)
It is possible, there are examples of Open Source projects which really do innovative new things, but they are quite rare. Part of the reason they are so rare is that a developer needs a thick skin to not be disheartened by the countless numbers of people around the O.S community who would rather nit-pick other people's efforts than contribute themselves.
uhhhhhh (Score:0, Insightful)
Re:Searching by content (Score:1, Insightful)
Baby, Bath water (Score:3, Insightful)
Don't throw the baby out with the bath water.
A "file" expresses a fundamentally useful idea: a clear demarcation of data that lives independent of the host filesystem. Once you start tieing and interweaving data tightly with the host filesystem, how do you export it without a significant, altering transformation?
That is, when someone "just emailed you the project", what did you get? How much of the filesystem did or didn't come along with it? Have we openned the door for Version Hell? Also, can the data be compressed without having to know that it is?
Let's just be careful to clearly define what we want and how we get it.
A "file" lets us abstract the data from the filesystem. It is then trivial for that data to live on Ext2, Ext3, FAT16, NTFS, Juliet, in a zip, in a tar, as an email attachment, or in a pipe to an arbitrary process.
With a "common data storage", it sounds like what is really wanted is for each "object" to emit a standard, common interface. Once everything has that interface, we can wrap a database system around it to transform the data in lots of unique, interesting ways. Is there something implicit about this new abstraction that it has to live in the filesystem instead of on it (Is-A versus Has-A inheritence)? Does it require that we to throw out other, existing, useful abstractions ("files") to get it?
It sounds like an equivalent solution is to encapsulate each file in a platform independent, self-describing data structure. Then, impose the database query system on top of that. That both maintains the separation between file and filesystem provides all the features of the "common data storage".
Re:As long as they get rid of file extensions... (Score:3, Insightful)
But the idea of the filesystem and files being basically one beast -- that's scary. Reminds me of a compressed volume file a la DoubleSpace/Stacker.
I'd expect the minimal effect would be a complete lack of access to my data except thru "approved" channels.
Worst case, when the OS does go titsup, my data goes with it (a la DoubleSpace), rather than being left in messy but recoverable files per older filesystems.
This may be great for big databases (billions of records and up) but I'll stick to discretely accessable files for my own systems, thank you.
Re:Clearing up misconceptions (Score:2, Insightful)
The possibility of the system breaking has also increased. Journalling, etc will only get you so far, and it has taken companies such as Microsoft and Oracle years to try and get that one nailed down.
There has been the means to provide index searching within Microsoft products on individual files since Option Pack 4 for Windows NT 4 came out. However it was not the best of index search engines, and there were a ton of problems in regards to maintaining the integrity of the index then. The product was not using SQL as it's database, and it was a real pain to try and make it interact with SQL (had to apply SP x, and then hot fixes, so you would not kill your database with the overload).
One of the issues then, was the ability to search on other file types such as PDF, etc. This was a right royal pain to setup. It is probably no easier now.
The reason for redevelopment of the applications is necessary to that you can have the new "search type fields" in your documents. However this ability exists now (Windows 2000), but the indexing capability is not the best, and still based upon the old system. To make matters worse, the indexing application has to do all of the interpertation itself (by calling a supplied filter DLL).
I guess the real important question is if the thing can be turned on or off, because not every installation of the OS will actually require a feature such as this, and the overheads will be sizeable.
We are slowly going down the path where we have so many features, bells and whistles that we end up confusing the poor users trying to use the damn thing.
Re:Is Linux too busy catching-up to innovate? (Score:2, Insightful)
But I'll answser to you, so we can keep the discussion going...
Think of today, not 100 years back. Think outside the academic environment. Think of an innovative idea. Doesn't the common sense tell you "sell it" or "make profit"? Where did all of companies come from? At&T, IBM, Apple, MS, (your list here)...
ONLY IF I didn't have the guts to carry on my ideas, or knew I couldn't do it without being smashed by the big guys... only then I wouldn't make a profit of it?
Imagine that... getting paid to do stuff I like! (I suppose that if you had an innovative idea, you actually do like the subject)
Whoa, Nelly!
Re:Extending the Unix doctrin. (Score:1, Insightful)
The idea that what was best for mainframes in the 70's is best for personal computers today is... well it's right up there with '640k should be enough for anybody'.
Re:It's about time (ACLs) (Score:2, Insightful)
Before Microsoft puts too much time into a new file system, I'd like to see it make full use of the existing NTFS one -- especially the ACLs. I'd like the OS and program files to be in an area that cannot be written to by anybody on the outside, or even by myself unless I'm logged on with a privileged account -- to eliminate any possibility of upgrades/viruses and other stuff getting installed over the net or from e-mails, etc.