Become a fan of Slashdot on Facebook


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

Next Windows to Have New Filesystem

Comments Filter:
  • Predictions (Score:3, Insightful)

    by PeterClark ( 324270 ) on Wednesday March 13, 2002 @12:32PM (#3156837) Journal
    It will be proprietary, obfuscated, and impossible for other operating systems to read/write to. Furthermore, it will have all sorts of copy management "features" built in to it.

    Yes, I'm cynical. But really, why shouldn't I?


    • Re:Predictions (Score:5, Insightful)

      by killmenow ( 184444 ) on Wednesday March 13, 2002 @01:19PM (#3157280)
      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.
      • Re:Predictions (Score:3, Insightful)

        by erasmus_ ( 119185 )
        Nice scenario, but not quite accurate. Just because the file system would be database-type, does not mean that SQL Server is going to be built in. For a good example of how Microsoft currently handles low-end storage utilizing SQL Server technology, look at MSDE (MS Data Engine) [], included with Visual Studio and also available as a free download. It's a scaled-down version, and certainly does not have all the querying or tools of SQL Srv. But the storage mechanism is similar. Likewise here, SQL Server would probably utilize the system, but Windows would not come bundled with it in any sense. Therefore, a statement that Windows will compete with Oracle out of the box is not supported by facts.
        • Re:Predictions (Score:3, Informative)

          by killmenow ( 184444 )
          I am familiar with MSDE. I think this, along with the JET engine and the Exchange version of JET is part of why it makes sense for MS to do this. From their perspective, you gotta figure it makes sense to simplify and have one scalable storage solution.

          I think:
          1. enough people who know a thing or two more about this than me are talking about it
          2. now MS is talking about creating an Object File System
          3. and we know SQL Server research has been going into making it handle less structured data more effectively
          I think it all points to credibility. That's not to say there won't be some add-on for additional SQL Server functionality, but I think it's believable that the core functionality of storing and retrieving objects in OFS will come from SQL Server.
        • Re:Predictions (Score:5, Informative)

          by Refrag ( 145266 ) on Wednesday March 13, 2002 @05:17PM (#3159191) Homepage
          MSDE _is_ SQL Server throttled for = 10 users and without the visual tools.
      • Re:Predictions (Score:3, Informative)

        by Zeinfeld ( 263942 )
        Think SQL Server 2003 = OFS

        I think you are right, at least in part. I think that the other issue to consider is the close relationship between WNT and VMS.

        The last major release of VMS with a major improvement was back in about '91 when they added in the low level support for transactions in the file system. This was a truly major breakthrough. it is a pity that it came towards the end of the VMS era and as a result was never really exploited by applications.

        The advantage of a transaction based file system is that you can write updates out to disk without having to worry about partial completion. You know that the write will either succeed completely or fail completely. It is not possible for the program to crash in mid write and leave the data in a corrupted state.

        This would be a major advantage for application programmers. You could get ACID properties without having to mess arround changing your data structures to use SQL. You would not need to deal with the twits who think that Entity Relationships are the latest thing in comp sci rather than what they really are, an obsolete throwback from the COBOL era. You would not need UML or any of that rubbish either. And you can hand your Oracle DBA their pink slip.

        All in all a win win situation, unless that is you are an Oracle DBA or hold Oracle stock.

  • that they can simply take FFS and Soft Updates and embed it in Windows, and call it OFS.

    Now that would be a substantial improvement.
    • by sql*kitten ( 1359 ) on Wednesday March 13, 2002 @12:47PM (#3156994)
      that they can simply take FFS and Soft Updates and embed it in Windows, and call it OFS.

      NTFS has features like ACLs, streams, etc that aren't in FFS or UFS. Also, support for transparent compression and encryption, also sparse files. There's support for quotas in the filesystem, and it's quite resistant to the effects of fragmentation. It's journalled and supports Unicode. It's actually a very good filesystem, once of the better parts of NT.
      • by blakestah ( 91866 ) <> on Wednesday March 13, 2002 @01:07PM (#3157193) Homepage
        NTFS has features like ACLs, streams, etc that aren't in FFS or UFS. Also, support for transparent compression and encryption, also sparse files. There's support for quotas in the filesystem, and it's quite resistant to the effects of fragmentation. It's journalled and supports Unicode. It's actually a very good filesystem, once of the better parts of NT.

        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.
        • BeFS...

          BeFS was/is essentialy a database, which in conjunction with features like extended attributes will allow you to store your mail as files in a folder (actually any folder). The same can be done w/ mp3:s where you can store the ID3 tag as file attributes.

          All this makes for lightning fast search of mail, mp3:s etc because it's all in the FS, there is no need for looking at the actually contents of a file.

          So now, do not say a database as a file system will not be to any use for the consumer...

          And, oh, ReiserFS seems to be heading this way too...
  • by tulare ( 244053 ) on Wednesday March 13, 2002 @12:33PM (#3156846) Journal
    Windows will also be less likely to break, and easier to fix when it does.
    Wasn't that the ad line for Windows ME?
  • by briggsb ( 217215 ) on Wednesday March 13, 2002 @12:34PM (#3156850)
    I hope this doesn't cause as many problems as the last feature [] they added.
  • This is probably in response to open source software people finally
    figuring out most of (the undocumented) NTFS. They don't want Linux,
    *BSD, etc. to be able to read and write their filesystem easily, as that
    would make it easier for people to dual-boot and/or migrate away from
    Microsoft operating systems.
    • I don't think that this is what they are after. It is possible that they will have to open their file i/o api's soon because of the anti-trust case here and in the EU. I truly (naively?) believe that they are moving to a better filesystem because it's a better filesystem, not because they want to break interop between *nix and MS. I'm also an eternal optimist.
  • by swordgeek ( 112599 ) on Wednesday March 13, 2002 @12:34PM (#3156856) Journal
    Note the historical sidebar on the article. It traces the on-again, off-again history of OFS. MS has been playing with it for over half a decade (!), and doesn't yet have anything to show for it. They've backpedalled and caught up again so many times that I think this article can be safely labelled as speculation.

    In other words, it sounds cool. I'll believe it when I see it. (and only at that point judge whether it really makes Windows less likely to break)
  • Can you say DRM? (Score:3, Insightful)

    by indole ( 177514 ) <fluxist&gmail,com> on Wednesday March 13, 2002 @12:36PM (#3156871) Homepage

    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.


  • ... my fat32 and NTFS seem to work okay... I dont think my concerns with microsoft are a result of their filesystems... this isnt a microsoft bash, I just think they would do better to focus their efforts elsewhere...
  • BeFS (Score:4, Interesting)

    by Lord Omlette ( 124579 ) on Wednesday March 13, 2002 @12:36PM (#3156873) Homepage
    It looks like BeFS with XML descriptions instead of MIME types. I think.
    • by hawk ( 1151 )
      Having finally implemented the Macintosh System 5.0 interface (multifinder)[1], they have moved on to taking features from Be. This will be followed by picking away at the Amiga carcass, after which it will turn back to Apple for those exciting Unix breakthroughs . . .



  • OFS? (Score:2, Funny)

    by Zaphod B ( 94313 )
    You mean Microsoft finally figured out that NFS was the way to go? Oh wait, we can't call it NFS... A,B,C,D..N,O! We'll call it OFS!


    This is just because people finally figured out their so-secret NTFS.
  • As an added bonus, entertainment pack 1 will include binaries required for recreational activities such as "OFS whacking". When asked to comment, Microsoft Spokesman v3.0 stated that 'whacking' without EP1 would invalidate the EULA and could result in system instability, a general sense of self-worthlessness, and pocket lint.
  • by FortKnox ( 169099 ) on Wednesday March 13, 2002 @12:38PM (#3156884) Homepage Journal
    From the article:
    Replacing its antiquated file system with modern database technology...

    Now, if you were going to base a file system on a DB, what would you use? An Object-Oriented DB? Where organization is key (which you want for a file system), or a Relational DB for speed (which is why they are claiming to switch)?

    I'm sure they are going to make a custom system, yes, but wouldn't it have to be based on one of the two major DB designs?

    For the record, I'm no DB Admin, but, as I understand it, relational is the choice of DB for almost all projects for its sheer speed, OO is only good for academic reasons to show off organization...
  • Metadata (Score:5, Informative)

    by Wanker ( 17907 ) on Wednesday March 13, 2002 @12:38PM (#3156888)
    It looks like Microsoft is trying to implement a standard (for Windows) metadata storage method. The've been trying to do this for years, but backward compatibility issues keep forcing them to abandon it. The Macintosh method seems to work OK, but is extremely limited in scope. It looks like Microsoft is planning something much wider scale. (The analogies to SQL are scary-- I hope they're just analogies and they don't mean to really implement a SQL-compliant database as a filesystem.)

    The GNOME project has an excellent overview of some of the issues with metatata [] in general.

    Of course, this will mean a whole new found of application incompatibilities on Windows and a whole new round of reverse engineering to determine the filesystem and metadata layout.

    • Re:Metadata (Score:5, Interesting)

      by Waffle Iron ( 339739 ) on Wednesday March 13, 2002 @12:59PM (#3157116)
      Actually, I think the basic idea goes beyond metadata. Ideally, data and metadata become one and the same, and you achieve "closure". Hans Reiser has a very interesting paper [] on this. It made me a believer.

      Unfortunately, Microsoft has exactly the wrong platform to implement these ideas on. The whole motivation behind this kind of thing is to simplify the software. Microsoft needs to be backwards compatible with 20+ years of cruft, and they have an abysmal record for writing clean, simple APIs.

      This will probably end up being just another popular software engineering idea that ends up being superceded by new business plans later on. It will become yet another ossified layer in the lower sediment of their future OSes (see DCOM, etc.).

  • UNIX: Everything is a file
    Windows: Everything is an object

    I guess it all comes down to whether they can make the surrounding environment rich enough that people can do everything they can do with objects as easily as they can with files (without writing a program).

    • Completely agreed. This extends the OO nature of Windows down to the FS level. .NET extends it up to the network level. It's a huge play by MS and it's a huge step forward.

      If only Windows Scripting Host gave you a more dead-easy way to script/tinker with the Windows objects...
  • 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.

  • Veritas? (Score:4, Informative)

    by lylonius ( 20917 ) on Wednesday March 13, 2002 @12:39PM (#3156908)
    From what I understand, Veritas essentially rewrote NTFS version 5 (shipped with win2000 and winXP) and
    integrated built-in volume management (dynamic disks) with some abstract layer to maintain the clunky drive letter schemes.

    I dont' really see the reasoning by mentioning that all Windows applications will require a rewrite; they only need to abstract the Win32::File APIs to handle the internal OFS changes... the changes that they document appear to do essentially what the Indexing services do for win2000 and winXP now. I assume it is just extra metadata strings that they associate with each file inode.

    It seems a bit arrogant of MS to think they can improve (or trash and rewrite) what is essentially Veritas' domain, file systems. But then again, we're talking about MS...
    • Re:Veritas? (Score:3, Insightful)

      by King_TJ ( 85913 )
      Yeah, it's probably far too early to tell what they really have in mind. (I doubt MS is really sure yet. If anything, they're probably still in the early stages of experimenting with different ideas to see what works best for them.)

      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.)
  • by Aexia ( 517457 ) on Wednesday March 13, 2002 @12:41PM (#3156930)
    Everyone would have to buy new versions of all their office software! Isn't that handy for MS?

    I'll pass. I may be running (pre-installed) XP on my Dell but I'm still using Office 97. Why?


    I don't need to "upgrade" to something even more bloated and bug ridden.
    • Everyone would have to buy new versions of all their office software!

      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
    • by Dr. Awktagon ( 233360 ) on Wednesday March 13, 2002 @12:58PM (#3157108) Homepage


      What are you saying, Citizen? You're not meeting your consumption quota? You're not upgrading when Central Planning issues Upgrade Orders?

      You're denying Microsoft their much-deserved Software Revenue! You're denying the Government their much-deserved Tax Revenue! How unAmerican! General Gates would not be pleased!

      You must upgrade immediately. Our helpful Upgrade Enforcers will assist you in all aspects (or will tie you to your chair if you are uncooperative). The new version of Office will be glorious, Citizen!

      (You know, the Communists had it all wrong. The best way to manage society is through central planning of Consumption!)

      • As a matter of fact, I'll bet you're a COMMUNIST PINKO who uses GPL software TOO HUH! I'm Dictator for Life Gates (Used to be General Gates, till I bought the presidency like Jeb's brother - but rather prefer the new title - President has such a limp ring to it!) and I don't want to hear that you're threatening the very economy by not consuming, and giving away things free! I mean, where would cappitalism be if I couldn't force you to work for me for a pittance, take your works, and make millions - not to mention what I can do to the consumers too!

        You're going to destroy capitalism!

        I'll even bet you complained about the DMCA too didn't you?!?! And the All American (TM) RIAA, and the Apple Pie (TM) MPAA! Did you know you're EVIL - we have ways to deal with you!a

        I'll just have to call in my thought policeman Herr Ashcroft and make sure that you're properly programmed. (That's part of that wonderful "for-the-children" legislation SSSCA - I mean I have to protect my IP, so you're required to be programmed to "respect" my IP

        Just stand right there, the men in black will be here shortly - resistance is futile.

  • My question (Score:3, Insightful)

    by kb3edk ( 463011 ) on Wednesday March 13, 2002 @12:41PM (#3156931)
    How long do ./ readers think it will be until the Linux kernel and/or Samba will be able to read OFS shares?
  • This sounds familiar (Score:3, Informative)

    by Cat Mara ( 211617 ) on Wednesday March 13, 2002 @12:43PM (#3156942) Homepage

    I remember MS talking about this years ago, even before NT came out. They were calling it Cairo back then.

    In the end, IIRC, the UI elements of the Cairo project were recycled into the Windows 95 shell and the Object File System concept disappeared entirely... until now, it seems.

    Is no-one else disturbed at the short memories in the industry? I was at the launch of Visual Studio.NET in Ireland a few weeks back and there was a Microsoft goon waving a Tablet PC around his head like it was some completely new thing. I mentioned the Go Corp/ Windows for Pen Computing FUD from the early '90s to the guys I was there with and was met with blank stares.

  • yay. (Score:3, Funny)

    by loraksus ( 171574 ) on Wednesday March 13, 2002 @12:43PM (#3156950) Homepage
    Gimme a D, gimme a R, gimme an M. . .
    What's it spell?
    I also see my ad filter is working on the new /. ads ;)
  • by Mr. Neutron ( 3115 ) on Wednesday March 13, 2002 @12:43PM (#3156952) Homepage Journal
    It would seem to me that IF Microsoft is going out of its way to develop a new FS, and IF that FS is not going to contain the copy-protection goodies that the entertainment industry is clamoring for, that Microsoft is basically thumbing its nose at the MPAA and RIAA, and siding fully with PC users and hardware manufacturers.

    Rather a good thing to know.

  • by km790816 ( 78280 ) <<moc.liamekaens> <ta> <20xg3qhqw>> on Wednesday March 13, 2002 @12:44PM (#3156955)
    I hope any changes that happen to the file system also include the removal of the antiquated concept of file extensions for type association. Here is another thing that Mac does very well. Imbed the type of a file IN the file. Why not give me a version number and some way to know what program created it.

    Back to the original topic, I can't wait for an OFS. Just for my MP3's. Figuring out which folder hierarchy to use for genre/group/album/track is a pain. Let the file system group them for me.
    • Why not give me a version number and some way to know what program created it.

      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)).
    • by Junta ( 36770 ) on Wednesday March 13, 2002 @01:19PM (#3157281)
      Getting rid of extensions is not necessarily a good thing...

      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 .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.

      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 /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.

      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...
    • Instead of relying on the extension to define file type, why not just read the file type from the header (or other clues) like some DOS utilities have been able to do for over a decade? Hell, I can do that much with my own eyeballs and a hex viewer.

      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.

  • Yikes! (Score:4, Funny)

    by sofar ( 317980 ) on Wednesday March 13, 2002 @12:45PM (#3156976) Homepage

    I hope they haven't discovered the unified file system, something which all the unixes use to store their data. We might be looking at the demise of unix!

    oh wait, where do we put Progra~1 then?

    - runs away to see if it's patentable
  • by madro ( 221107 ) on Wednesday March 13, 2002 @12:46PM (#3156988)
    A slightly different angle on this is available in an older Register article [] from last July, "MS poised to switch Windows file systems with Blackcomb." From the article:
    From a historical perspective, the vision of Cairo will have truly come full circle. Back then, Microsoft promised a proper directory service, messaging, cross-machine working, a fluid and customisable user interface experience, and unified storage. Active Directory gives the first, Exchange Server gives the second, Common Runtime/SOAP/ XML gives the third, HTML/XML/XSL/IE gives the fourth, and Yukon's children give the latter.
    For all their illegal business practices, Microsoft's one-stop shop approach (integrating/co-opting standards when necessary/appropriate) makes them tough to beat. I just hope it's like the Mac commercial where the last line from Big Brother is "We shall prevail ..."

    ... right before the sledgehammer hits.
  • by ka9dgx ( 72702 ) on Wednesday March 13, 2002 @12:46PM (#3156989) Homepage Journal
    "The goal is to enable searching not only by file name, but by file content."

    You can achieve this goal by the following process:
    1. Store all of your documents in a simple, text based format, and not in some overly complex propriatary format such as ".DOC", ".PDF", etc.

    1. This text based format is known as "American Standard Code for Information Interchange" (AKA "ASCII")

    2. If you require more complex presentation of information, you might want to use something called HyperText Markup Language. (Which doesn't do much markup these days... but I digress)

    3. There is a program built in to Windows 98 and above called "Find" (usually accessed by hitting F3), and in other environments known as "grep" which can search by content.

    Use the tools you have, you won't have to "upgrade" to the latest bugs, and the computer remains useful.


    • by Yarn ( 75 ) on Wednesday March 13, 2002 @01:03PM (#3157155) Homepage
      I do this by putting everything on my webpage and letting google sort it out :)
  • Obsolescence (Score:3, Interesting)

    by asv108 ( 141455 ) <.asv. .at.> on Wednesday March 13, 2002 @12:50PM (#3157023) Homepage Journal
    Now I wonder if the next version of office will only work on the longhorn release since it makes use of the new filesystem or will MS play nice and make it compatible with 2000 and XP. I could see this file system being a great way for MS to force people to upgrade their OS if they want to use the new office. I love how office XP and 2000 only work with windows 98 and higher. What major difference would prevent office working on windows 98 and not Windows 95? I could see the same thing happening in a more drastic fashion with this next release. I guess Microsoft's strategy by then is that all their major customers will be under a subscription plan with forced upgrades.
  • by damieng ( 230610 ) on Wednesday March 13, 2002 @12:51PM (#3157030) Homepage Journal
    Early versions of BeOS had a full object orientated file system and found performance was abysmal. This was from a company with no backwards compatibility to worry about and a small OS designed for speed.

    In the end Be developed BFS which is basically a standard file system with support for indexes and attributes, an overall much better performing system with most of the benefits of an object orientated file system.
  • by erroneus ( 253617 ) on Wednesday March 13, 2002 @12:56PM (#3157079) Homepage
    Maybe the rest of the world has a short memory, but I don't.

    According to what Microsoft had announced some time ago, they are HALTING further new development while they focus on bug fixes. Can I then take this as a sign they've fixed all the problems with Windows?

    So now they are working on new developments again? I'm pretty sure existing Windows is not completely stabiized...I know mine isn't. So what does it mean? Micrsoft can't maintain focus? They can't tell the truth? What?
  • Specific tech info (Score:5, Informative)

    by The Bungi ( 221687 ) <> on Wednesday March 13, 2002 @12:56PM (#3157080) Homepage
    Unfortunately the article doesn't go into much technical detail. As far as I've heard from some people in "the know" (if you can go that far) is that the new FS will be based on some beefed up version of SQL Server. That much is apparent. However, this version will be enhanced with ORDBMS-like capabilities, which SQL Server doesn't have today. It will also be tied heavily into Active Directory. That much I do know.

    Now for some speculation. The implementation is likely to be based on the same "pluggable" FS driver architecture first introduced in Windows 2000, where the NTFS and FAT32 drivers are just a layer on top of the kernel (you can actually buy a devkit from Microsoft that will allow you to implement, say, ReiserFS for Windows 200). This however poses an interesting question: do you make this newfangled FS to sit on top of tried-and-true NTFS, or do you implement it at the kernel level and make NTFS a layer on top of that? Either way, I think the article is overstating the devastating effect on existing apps. Microsoft is not about to shoot itself in the foot so massively. Whatever this ends up being it's a good bet it will be fully backwards compatible. Kinda like Win32, which can still run 16-bit apps, albeit slower (in 2K and XP). But this will make companies more likely to either port existing code or release newer versions that take advantage of the redesigned FS.

    There's a interesting Register article here []

  • by Auckerman ( 223266 ) on Wednesday March 13, 2002 @12:56PM (#3157081)
    It really is an interesting problem. My Wife's iMac only has a 6Gb drive. She's always saving info form the web into AppleWorks files. She has generating a LOT of little itty bitty files. Now our PC file server stores our digital photos and mp3s, and both iTunes and iPhoto make managing that mess quite easy and Sherlock is SUPPOSED to make finding in files easier (it kinda does), but does a poor job at it.

    Now, my point is, I've actually thought about setting up some form of database so that my Wife can find her info for years to come. But my biggest question is NOT would a database help, I'm sure it would. What I would like to know, is how would the interface for that database look?

    Considering what I have seen of XP (I got a copy sitting on a 2GB drive that sits on my shelf), MS knows very little about information management in the UI, and I would expect this problem to not get any better for the majority of PC uses, even if the entire file system was one big database.
  • The Point (Score:5, Interesting)

    by rabtech ( 223758 ) on Wednesday March 13, 2002 @12:58PM (#3157100) Homepage
    The point of this new data store isn't necessarily faster searches, although that is one part of it. The idea is to have a common data storage mechanism, used by all programs.

    The underlying technology is to replace the NTFS filesystem driver with SQL Server, with a few tweaks. SQL Server already supports using a RAW partition as a data store, so essentially you just have to move the transaction log and descriptive info for the databases into a specific area of the disk. Add a little bit of bootstrap code to ntldr, and slap the SQL Server stuff into the startup driver list, and it's a done deal.

    The next step is creating an NTFS compatibility layer -- it would allow you to mount tables as drive letters or network shares. A lot of the information wouldn't be useful when viewed in that fashion, but it would give you a way to run older programs.

    Once all your data is in a common data store and can be manipulated as such, it opens up a world of new possibilities. The change will be long and slow; no need to kid about that. It will take years for all the 3rd party programs (and even Microsoft's own apps) to catch up and start taking full advantage of it. It's the same situation Plug & Play was in back in 1995; it sorta worked sometimes, but you couldn't really take full advantage of it. But here in 2002, you really can expect to grab a piece of hardware and slap it in your box without hassles. It took some time, but it eventually paid off.

    But... are you having trouble, as I did, thinking of ways to make use of this common data store? Part of that comes from the fact that we've been conditioned and trained to think of data storage in terms of files; it's hard to shift gears... to think outside of the "filesystem" box so to speak.

    For one thing, I could see someone emailing me a project. Not some word documents, an excel spreadsheet, and a database zipped into a ZIP file; they just email me the project. When I get it, and open the message, the project opens up presenting me with the various documents (linked to the database of phone numbers for example), and a little yellow stickynote window that has the project leader's actual email text. I didn't have to deal with unzipping the data, rearranging it, then opening the documents separately. Since the "rows" are linked, they open and act as a unit until I tell them to do otherwise.

    It gets better though... imagine if I could run a query such as "SELECT f.*, s.filename FROM Folder1 f INNER JOIN folder2 s ON f.datetime = s.datetime"

    It can get even more useful because you now have full SQL syntax available to you for manipulating the filesystem, with queries that are lightning fast. Throw in some Stored Procedures, Functions, Views, etc and I can see real possibilities.
    • Re:The Point (Score:5, Interesting)

      by costas ( 38724 ) on Wednesday March 13, 2002 @01:30PM (#3157375) Homepage
      Hmmm... A few thoughts that this enables:

      Version control a-la VMS anyone? the FS is a full RDBMS, it could potentially store transaction history so that you could have multi-level undo at the FS level (eat that, Veritas).

      Separation of file content from metadata? Sync your word file to your PocketPC and that device only gets the data it "knows" about (a "consumer" which only understands certain "interfaces", if it helps to think of this that way).

      Virtual directories? screw the strict hierarchical view of the world. Directories can finally be SQL queries! I mean they are now, but they only depend on the filename and path. Imagine a directory that literally is the result of the query "all files that were sent to this customer in the last 2 months". Seamless.

      Network transparency. I posted this in another comment. This pushes the windows object orientation down to the FS. Dot-NET pushes it up to the network. RDBMS can already support redundancy and clustering. Take that concept to the NFS/distributed computing level.

      This is a huge technological leap forward. We've been working on super-powerful DBs for years, but we were limited to a stupid tree when it came to our own personal data management. This is big.
    • Baby, Bath water (Score:3, Insightful)

      by RovingSlug ( 26517 )
      Once all your data is in a common data store and can be manipulated as such, it opens up a world of new possibilities. ... we've been conditioned and trained to think of data storage in terms of files... I could see someone emailing me a project. Not some word documents, an excel spreadsheet, and a database zipped into a ZIP file; they just email me the project.

      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".

  • by Anonymous Coward on Wednesday March 13, 2002 @12:58PM (#3157103)
    And IBM's AS400's have been doing this for years. Not to mention BeOS. ReiserFS is of perticular intrest because it will allow for attaching of arbitrary objects to any node. Only problem is we have five next generation file systems duking it out so generic Linux will most likely not see the benifits for some time as nobody will want to program specificly for a filesystem that reaches only a fraction of the usebase. It would be sure nice though to not to have to see .nautilus-metafile.xml stewn about my file system. sigh! What would be nice is generic system calls for filesystem metadata that would write out .nautilus-metafile's for FS that don't support metadata and node metadata for FS's that do. Of course we would need a standard format but it would be instantly useful.
  • There was an article on slashdot a while back that linked to this [] little gem from Cringely about "The Death Of Internet Innocence" and how he thought that MSFT might introduce a new internet protocol to replace TCP/IP and purport it as a way to stop hacking, security breaches, solve all your problems, etc, but it was really just another brick in the monopoly.

    The submission form is acting weird so here is the link again: html [].

    This New File system sounds to me like something similar.

  • by jonbrewer ( 11894 ) on Wednesday March 13, 2002 @01:02PM (#3157146) Homepage
    They proved with AS/400 that using a DB for the file system was the way to go. It's too bad they did it way ahead of their time.

    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.
  • by Anonymous Coward on Wednesday March 13, 2002 @01:03PM (#3157160)
    Everthing is a file, says Unix.
    But that was 30 years ago. Perhaps its time to extend the unix-doctrin: Everthing is a file and a directory.
    Why? Metadata.
    Todays file-formats store informations about the file inside the file (thing id3-tags) or abuse file-attributes (such as the filename(.html)).
    With files as file and directory, there would be no need for that. Imagine: you store informations about the authors of a file inside metadata-attributes. There would be simple possibilities to search for these informations, so one could easy pick up all "draft" files inside a direcory (ls -al *../status=draft, maybe)

    • Everthing is a file, says Unix. But that was 30 years ago. Perhaps its time to extend the unix-doctrin: Everthing is a file and a directory.

      And 30 years ago the bleeding-edge filesystems (non-UNIX) did have metadata and resource forks and other whizbang ideas. Guess what? They sucked. You can't pipe a multistream file. You can't send it over the network. You can't dump it to tape. First you have to convert your whiz-bang metadata enabled file into a "bag of bytes" file. This means you need to manually add an additional "convert to bag of bytes" step before you do anything unusual with a file. UNIX removes the complexity by forcing the applications to save into the "bag of bytes" file format from the start. The metadata is still within the file, but the application put it there, and the application knows how to get it out.

      The UNIX people chose simplicity over complexity. History has shown that if people want metadata then they can implement it inside their applications (ID3 tags, TAR, GZIP headers). This is one of the many reasons why UNIX still survives: it dictates the means to store data, without enforcing a policy about what data is stored. Applications can then grow and evolve to include new-and-unthought-of metadata. This would not be possible if the UNIX filesystem had forced a restricted set of metadata onto everybody from the start.

      People who don't learn history are doomed to repeat it.

  • Good. (Score:5, Interesting)

    by NetJunkie ( 56134 ) <jason DOT nash AT gmail DOT com> on Wednesday March 13, 2002 @01:03PM (#3157161)
    NTFS is a very solid filesystem and seems to recover problems well when something bad does happen. The only complaints I have are slow searches and reports. It takes a LONG time to find a file on a big volume, or try and do reports on file system usage. A good database system should speed that up tremendously.

    The idea of having to rewrite the apps is interesting though. That tells me this is at least 5 years off, and longer before it would be used widescale. But I guess that makes sense, would you be the first shop to put your big fileserver on a new filesystem like that? Not me.
  • by AdamBa ( 64128 ) on Wednesday March 13, 2002 @01:06PM (#3157177) Homepage
    "Replacing its antiquated file system with modern database technology should also mean a more reliable Windows that's less likely to break and easier to fix when it does, said analysts and software developers familiar with the company's plans.

    In the process, the plan could boost Microsoft's high-profile .Net Web services plan and pave the way to enter new markets for document management and portal software, while simultaneously dealing a blow to competitors."

    OK I know FAT is antiquated, but NTFS is modern. In fact I recall it was announced at some point 3-4 years ago that OFS wasn't necessary because all the relevant features were being merged into NTFS? Maybe that was an internal announcement, one of the annual "we are finally merging our data stores" emails the top Microsoft brass would send out to the troops.

    Anyway I don't see why this would make Windows less likely to break or easier to fix, or what it has to do with .NET...why does that kind of marketing fluff have to be included in a pretty reasonable article (and the sidebar is very nice)?

    - adam

  • by Sanity ( 1431 ) on Wednesday March 13, 2002 @01:13PM (#3157230) Homepage Journal
    Whether you like Microsoft or not, you can't deny that they are willing to take risks and innovate, this being a perfect example. My question is whether the Linux community is capable of doing the same, or whether we will always need to wait for someone else to do something before we consider it.

    It is funny, we accuse Microsoft of using other people's ideas - but are we really any better? How much of Open Source development is really just reimplementations of other people's ideas?

    • Exactly how is this a risk to M$? If this new FS doesn't fly, do you think they are in trouble as a company? Ha. Not bloody likely. That isn't taking a risk at all. They could simply up their subscription fees by $1 and make up their losses.

      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.

  • by biwillia ( 35276 ) on Wednesday March 13, 2002 @01:17PM (#3157260)
    When I read this article, I immediately had two thoughts:

    Thought 1: "You know, they're right" Current file systems are outdated and are not really serving the needs of modern applications. Take for example, Microsoft Outlook (and Outlook Express). The programming teams for these pieces of software were forced to implement a "filesystem within a file" in order to achieve their design goals (I believe the files are called DBX files). Or take for instance, the Windows Registry, or, even better, the Gnome registry, GConf. Why do programmers have to implement dozens of different abstract filesystems in order to achieve their design goals? Simple, the present filesystems are not sufficient.

    Thought 2: "Another way of attacking the Free Software Movement." By creating a new filesystem, Microsoft achieves many goals. First, they make Linux filesystem developers start from scratch again. I mean, the NTFS driver isn't even done, and this means we would have to start over. It gets even worse: From the sound of this article, it seems that OFS would be fundamentally incompatible with our conception of a filesystem today (possibly including features such as resource branches, GUID tags, and other metadata forks, ad nauseum). This would make it difficult to write a usable Linux driver for OFS. And finally, to top it off, my gut tells me that the POSIX file access calls would _not_ be sufficient to access such a rich filesystem. The introduction of a new, richer file access API by Microsoft would make writing cross-platform software much more difficult.

    Microsoft can kill two birds with one stone here.

  • BeOS lives! (Score:3, Interesting)

    by babbage ( 61057 ) <cdevers@cis.usoutha l . edu> on Wednesday March 13, 2002 @01:19PM (#3157275) Homepage Journal
    You know, for all the journalistic puff pieces that came out last year comparing WinXP to MacOSX, I never saw one that seemed to realize that these systems had been in more or less closed development for years, and couldn't possibly have been cross-pollinating as much as the writers seemed to be saying. OSX, of course, draws heavily from NEXTstep for obvious reasons. Much more interesting to me is, in my opinion, the way that Windows seems to be evolving in the direction that BeOS once stood.

    If you take a look at the XP interface, it feels (to me at least) a lot like a candied up BeOS -- a lot of the icons have a similar look, there's the grouped taskbar items a la the BeOS tracker, etc. And seeing as BeOS has been around for years, it makes a lot more sense that the Microsoft engineers would have been able to start reimplementing ideas like this by this point.

    And now we start seeing articles like this one, and it becomes clear that just as the XP interface has started to resemble BeOS, the XP native filesystem is starting to resemble BFS. This isn't the first time in recent months that we've seen reports of this -- not long ago there were articles saying that MS wanted to ditch Access and it's Jet engine (or whatever it runs now), and turn the SQLServer engine into the core of the next generation filesystem. This is of course exactly what Be wanted to do, but couldn't due to performance constraints, so they went with the scaled back object oriented system instead. Hey look at that, now we hear that Microsoft is also going with an OO-FS instead of a full SQL-FS.

    Microsoft already ran Be out of the market, and are rightfully getting sued now for doing so. I wonder if Be would be willing to use this increasingly familiar evolution for Windows as evidence that Microsoft wanted to eliminate their strongest OS competition while ripping off all their good ideas. As much as it's vindicating to see that BeOS's best features will live on in new versions of Windows, I'd rather have the chance to see the original around today...

  • Registry Redux (Score:5, Insightful)

    by Anonymous Coward on Wednesday March 13, 2002 @01:22PM (#3157306)
    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.
  • by drew_kime ( 303965 ) on Wednesday March 13, 2002 @01:28PM (#3157362) Journal
    "We've been working hard on the next file system for years [since the early 1990's], and -- not that we've made the progress that we've wanted to -- we're at it again," Ballmer said.

    While the Cairo project eventually resulted in Microsoft's Windows 2000 operating system, the file system work was abandoned because of complexity, market forces and internal bickering. "It never went away. We just had other things that needed to be done," Jim Allchin, the group vice president in charge of Windows development, told

    Those other things most likely included battling "Netscape and Java and the challenge of the Internet and the Department of Justice," Gartner Group analyst David Smith said--issues that continue to persist today.


    The more important reasons for the renewed development effort, however, are strategic. If the plan succeeds, it will give Microsoft a huge technological advantage over the competition by making its products more attractive to buyers and giving large companies another reason to install Windows-based servers.

    So if they hadn't been trying so hard to kill off Netscape, they would have had the time to spend on creating this. Something that seems to offer actual advantages to the user, and that would be "a huge technological advantage over the competition by making its products more attractive to buyers."

    I wonder how many other genuine advances have been put on hold in the name of detroying someone else first.
  • by Salamander ( 33735 ) <> on Wednesday March 13, 2002 @02:03PM (#3157608) Homepage Journal

    A lot of people seem to've totally missed the point of what would be different about a database-oriented filesystem. File extensions? Not bloody well relevant! Let's consider the issue of searching. A database-oriented filesystem might allow you to create directories that are basically "views" of your filesystem, perhaps including all files that meet certain name, attribute or content criteria (like Evolution's vFolders but available to any app). These views would be up-to-the-instant accurate at all times, with no dead links and no problem with apps replacing links with actual files instead of updating the file that the link pointed to. Filesystems could also benefit from other things like referential-integrity checks, triggers, and cross-file transactional behavior. In fact, there has been a lot of work in the kernel-hacker community to figure out how just that last feature could be added to Linux filesystems. Basing a filesystem on a database also allows you to leverage all of the tools (e.g. efficient snapshots and replication) that have been developed for the database. There's a lot more here than just journaling and BeOS-style metadata.

    It's not that I think basing a filesystem on a database is a great idea. For one thing, it's a pretty good bet that performance is going to suck because of all the extra DB-related overhead. Administration might become more of a PITA too. I'm just trying to explain that the idea of a database-oriented filesystem has much broader implications than the trivial crap (much of which is relevant to neither filesystems nor databases) that people seem to be focusing on in this thread so far.

  • Summary (Score:4, Funny)

    by Hard_Code ( 49548 ) on Wednesday March 13, 2002 @03:06PM (#3158158)
    First Slashdotter: MS is coming out with a new "revolutionary" file system! *bash* *bash* *bash*
    All Slashdotters: Burn it! Burn it!
    Rational observer: Well, how do you know it's so bad?
    First Slashdotter: Well, it's from...MS!
    All Slashdotters: Yeah! Yeah! Burn it! Yeah!

Air is water with holes in it.