Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Data Storage

CNet on WinFS 466

Posted by michael from the ronco-vegematic dept.
Weston writes "CNet has posted an article about WinFS, or more specifically, what Bob Muglia (a VP at Microsoft) said about it in a recent interview. According to Muglia, the new filesystem will not replace NTFS, but will incorporate feratures of NTFS, SQL, and XML all into a filesystem which, accoring to Microsoft, will open up a whole new world of information availability. He goes on to describe such a filesystem as the 'holy grail' that is sought by developers. WinFS is slated for release in 2005/06 as part of the Longhorn OS."
This discussion has been archived. No new comments can be posted.

CNet on WinFS More

CNet on WinFS

Comments Filter:
  • Filesystems are just inefficient, shitty databases.
    • Filesystems are just inefficient, shitty databases.

      if by efficiency, you mean "speed of read and write" then i don't think this is going to be an improvement. the article makes it sound (although it's short on details) like winfs is just a front-end for ntfs and sqlserver - another layer your read-and-or-write has to go through before it gets to the disk.

      but, hey, it's got xml for buzzword compliance!

    • Instead of just saying it, you should have done something about it. Imagine the riches you could be rolling around in if you had sold a revolutionary new filesystem to BillyBoy. Or imagine your name spoken with the same respect and awe as Torvalds, etc, if you open sourced it.

    • Re:Been saying it for years (Score:4, Insightful)

      by orthogonal ( 588627 ) on Friday October 17, 2003 @10:56AM (#7240284) Journal
      Filesystems are just inefficient, shitty databases.

      And sometimes all I want is a shitty database.

      What worries me is that Microsoft already overrides my wishes; if they think they've created the "holy grail", they'll be even more likely yo impose it on me even if I know it's not what I want.

      Case in point: Windows 2000 and above has no problem reading FAT32 partitions greater than 32GB in size. But it refuses to create FAT32 partitions > 32GB in size. Why? Because at that size, Microsoft knows better, Microsoft knows you should be uses NTFS and get the benefits of meta-data and journaling.

      Except, I don't want the overhead for my MP3 collection. The meta-data's already present in the ID3 tags, and I don't need journaling -- once the ID3 tags are written, they're essential read-only. I want low overhead storage for very large (several MB) files.

      And I want something that is a mirror of my portable plaayer, which can only read FAT32, can only read the first partition, and is 60GB. Since my portable only reads FAT32 (but doesn't format), and since Microsoft, in its wisdom knew better than to allow me to format it as FAT32, instead I got to watch it run the drive for over an hour before telling me the partition was too big. Talk about a linux killer app: I nearly had to switch to linux if I wanted to be able to use my portable.

      Fortunately for me that the open-source world exists: somebody had actually compiled the linux mkfs for cygwin, and I formatted the portable with it. I can't use Windows' chkdsk on it, of course, and I haven't yet looked at compiling fsck under cygwin to further work around Microsoft's collosal arrogance.

      Given my experience, if Microsoft thinks they have the "holy grail" of filesystems, it, and Microsoft's arrogance, will once again be rammed down the throats of every Microsoft user. But by that time, I'm sure I'll have fully transitioned to linux.
      • So use FDISK. It's still free if you own Windows.

      • What worries me is that Microsoft already overrides my wishes; if they think they've created the "holy grail", they'll be even more likely yo impose it on me even if I know it's not what I want

        They can only impose their will on you if you let them. You can just say "enough" and move to a Mac, Linux, *BSD, et al.
      • "Case in point: Windows 2000 and above has no problem reading FAT32 partitions greater than 32GB in size. But it refuses to create FAT32 partitions > 32GB in size. Why? Because at that size, Microsoft knows better, Microsoft knows you should be uses NTFS and get the benefits of meta-data and journaling."

        There may be a far-less-nefarious reason why it won't let you create a FAT32 partition of size >32GB, namely that the FAT table would be ridiculously large and inefficient.

        Now, you could argue that
      • Ok, people were up in arms that NTFS would have SO much overhead that it would never be viable in desktop PCs(1992 Buzz). And here we are again...

        However, even on the 486-33mhz 16mb Systems that NT 3.1 and 3.51 were released on showed that NTFS's performance was at the same level and sometimes much faster than less featured FS technologies like FAT, etc.

        Ironically, Journaling is still seen as a major overhead on OSes like OSX - which baffles me, considering MS was able to offer great journaled performanc

    • Re:Been saying it for years (Score:4, Interesting)

      by penguin7of9 ( 697383 ) on Friday October 17, 2003 @11:55AM (#7240985)
      Filesystems are just inefficient, shitty databases.

      The fact that file systems are databases has been recognized since, oh, databases were invented. One of the first things IBM tried after inventing the relational database was to replace the file system with it. You can tell how far that went.

      The choice to make the UNIX file system the kind of database that it is was deliberate. UNIX file systems are a highly efficient and robust database, with proven metadata, security, and data consistency models. They do almost exactly what people want databases to do with their unstructured data.

      For anything else, they use other databases. By a stroke of genius (or maybe just historical inevitability), those more specialized databases can be stored and accessed inside the file system database.

      A database file system is quite accurately described as "The Holy Grail": it's an ancient mythological object of no practical value, something that only insane people would pursue.

      • One of the first things IBM tried after inventing the relational database was to replace the file system with it. You can tell how far that went.

        What do you mean? To this day IBM uses a database AS the filesystem in the AS/400. Ever heard of DB/2?

  • Corrupt filesystems faster, (Score:4, Funny)

    by Trigun ( 685027 ) <evil&evilempire,ath,cx> on Friday October 17, 2003 @10:13AM (#7239856)
    easier and more irrevocably!

    Yay!

  • the 'holy grail' that is sought by developers. (Score:3, Funny)

    by 3.5 stripes ( 578410 ) on Friday October 17, 2003 @10:16AM (#7239895)
    They should have a look in the castle ARGGGHHHHHHHHHHHHH, then.

  • What about those of us (Score:4, Insightful)

    by Zelet ( 515452 ) on Friday October 17, 2003 @10:16AM (#7239898) Journal
    who like the filesystem the way it is. I can find any file in my system within 3 or 4 clicks of a mouse because I keep my files organized. How is the new system going to be faster than that? I don't understand how searching for files every time you need them is faster than a file system hierarchy.
    • who like the filesystem the way it is. I can find any file in my system within 3 or 4 clicks of a mouse because I keep my files organized. How is the new system going to be faster than that? I don't understand how searching for files every time you need them is faster than a file system hierarchy.

      Maybe not for us, but many people don't have that kind of hierarquical organization, and thus searching is faster.

      I would suspect that XML will be used to store metadata from files, and not the files by thems
    • What about those of us who like the filesystem the way it is. I can find any file in my system within 3 or 4 clicks of a mouse because I keep my files organized. How is the new system going to be faster than that? I don't understand how searching for files every time you need them is faster than a file system hierarchy.

      Well, a file system is already a database, albeit a fairly poor one. Directories and sub-directories are essentially just fields attached to the record for each file. The new one will still

    • I agree.
      In fact i would rather have a lightning fast filesystem and use special software to scan and index special data (ID3 tags , Documents info, etc) than have it into the filesystem.
      After all, the programs most users use to look up files could very well do such jobs as display Id3 tags and snapshots (eg Nautilus does a good job). Combined with a userspace program that scans and indexes stuff (lets say something "like" GTKtalog ) then you would have a disk that is searchable. Not to mention that if
    • If you've seen OS X Panther's new search capabilities, you'll know how fast things can be: live recursive searching. It's pretty sweet. Works in the finder, as well as Preview for PDFs.
    • I keep my files organized.

      A standard file hierarchy is a database with only one dimension, and one hierarchy. You can organize with one first level characteristic, then for each of those subtrees, one 2nd level, and so on. A database lets you have multiple hierarchies simultaneously.

      You don't lose organization, you gain multiway organization. The real issue is that you need something better than the typical flat directory listing or tree listing to view the structure of your data. MS needs to combine

  • NTFS + SQL + XML + buzzword compliance? (Score:5, Insightful)

    by Gothmolly ( 148874 ) on Friday October 17, 2003 @10:17AM (#7239903)
    Why not a little Java thrown in? Or DRM? or TCPA? Or (insert hot new technology here) ?
    This seems classic MS-predictive-FUD, where people hold their breath for the Next Release, which is a 1.0 version that sucks. Meanwhile, support people and PHBs have committed to it, so its Too Important To Let Fail. Ultimately, it becomes a time and resource sink the likes of which is only matched by /dev/null, all the while funding MS and driving them to an eventual 3.0 or 4.0 release, which will be Decent, Yet Still Subtly Lacking.
    All of this won't help the average user find files easier, and will be massively more bloated and complex (read: too many moving parts, read: Service Pack Hell), and probably REQUIRE that Athlon-64 system we've been drooling over.
    • Don't forget to throw some .NET in there too.

      I'm actually surprised it's not being called .NETFS. I suppose it's because you'd have to use ls -a to see it. :)

    • Why not a little Java thrown in? Or DRM? or TCPA?

      I'd we willing to wager that TPCA (and indirectly DRM) will be fully supported by this new filesystem. However, they have to introduce it in such a way that consumers don't realize they made a new file system just so they could more fully control the contents of people's hard drives. So, instead they tell you how fast and efficient it is.

    • NTFS and SQL are Buzzwords? Is this 1991?

      And how exactly is this FUD. Where is the Fear? Where is the doubt? Where's the Uncertainty?

      You also say

      Meanwhile, support people and PHBs have committed to it, so its Too Important To Let Fail

      Wouldn't you mean 'developers' and PHB have committed to it? Support people are always the last to change, and hate it the most.

      Look, WinFS is a document repository. It's a good thing if you work with or build document management systems. Because right now, Document Managem

  • Thoughts on XML (Score:5, Interesting)

    by I8TheWorm ( 645702 ) on Friday October 17, 2003 @10:18AM (#7239916) Journal
    I use XML quite a bit in my data-based programs. But I've seen it used WAY too often and in applications where XML just doesn't make any sense (like parsing 1GB files, for instance). XML is a nice tool, but isn't the fastest way to get to data.

    That being said, does anyone else think using XML in a filesystem is a horrible way to go? Especially given the hard drive capacity we're seeing today... number of files that can be stored, folders/subfolders, etc...

    Unless I misread the article, I just don't see this being a smart move.
    • Everything I've heard about XML and WinFS has been so vague that what I'm hoping they mean is the file system information is going to be exported as XML and the underlying system for storing it won't be XML.

      This makes an amount of sense - if you want to send a file and maintain the metadata about it, you package it into something that contains the XML file to make it future proof (supposing the format changes, say, because another OS comes too close to being able to read/write WinFS) and the actual data s

      • You make two good points. sound like someone's playing Buzzword Bingo and file system information is going to be exported as XML and the underlying system for storing it won't be XML.

        One would hope they're planning on using it as an outside repository just for the metadata, but even then, it's doomed to become extremely bloated. Hopefully, it would not be tied directly into file properties, and you would have the option to use it or not at that point
    • XML is a nicer way of storing meta-data than traditional DB tables, since you don't have to define the fields before you use them. If it is only used for meta-data (and not for inode tables / FAT) then it shouldn't slow down the system much, as long as the indexing service parses it nicely. I suspect that they are hoping that by the time WinFS is actually ready everyone will have 3GHz+ CPUs, and won't care about the overhead.
    • I can see it now...

      ...
      <data file="myfile.zqp byteIndex="1">0x2b</data>
      ...

      Boy, am I excited.

    • Re:Thoughts on XML (Score:4, Interesting)

      by ajs ( 35943 ) <ajs@ajs . c om> on Friday October 17, 2003 @11:04AM (#7240381) Homepage Journal
      This is not a new concept, and it does work out ok.

      Your basic linear span of bytes file type becomes a subset of all possible data-structures. Structured file filesystems with various semantics have been around since the 70s (perhaps earlier). XML gives you a way that everyone can agree on to store the schema (of course you'd use a binary XML representation on disk, and have a few prefab schemas (like the DBM type key-value pair) hard-coded into libraries for speed).

      This is a good idea, and perhaps one of the few places that I've heard people talk about using XML at a low level that I would agree with in princable.

      Of course Microsoft will get it wrong. Because they're idiots? Not at all, there are a lot of bright people there, but Microsoft's priorities are set by their largest customers and for those customers and for marketing reasons, they make some truly AWFUL descisions, like consolodating the Win32 API and throwing away the multi-tiered, user-space service approach that NT was originally supposed to have on top of HAL and the NT microkernel. That was done because MS saw a need to give their largest base of developers (corporate in-house mostly) as close to a seemless transition from Win3.1 as possible, and for no real technical reason that had to do with NT.

      That ruined what was likely to to have been one of the coolest pieces of software that Microsoft would have ever produced. NT (now the heart of XP and Longhorn) is still a cool OS at its core, but as I expect to happen with this filesystem, it was so hobbled by the needs of their business customers that it took a decade to extract any real value from that.

      I'm not MS-bashing. I'm a Linux/UNIX/BSD user, but I'm willing to accept that good developers work on all sorts of software, open and proprietary. The problem is that the larger a software business is, the less voice the developers have.

      Personally, I'm waiting to see where Reiser goes...
  • Sounds like WebDAV [webdav.org] + Catacomb [webdav.org] to me.

  • Do you guys really think (Score:2, Insightful)

    by rhinoX ( 7448 )
    that the NT and NTFS teams would allow the SQL Server group to take such a huge chunk of control from them? You've got to be kidding me! The filesystem will not be anything new. The SQL guys at MS have been trying to move to a DB FS for a while, but let's face it - the performance will absolutely SUCK. At most, this is SQL server for metadata slapped "on top of" NTFS, period.
  • ...an XML-based filesystem; i can imagine the speed now
  • Merlin: "Uther, say the words."

    Uther: "ONE LAND, ONE KING!"

  • Cool (Score:2)

    by Pedrito ( 94783 )
    Look, I hate to say it, but I've kind of been looking for this capability in a file system. So much so that recently I had been thinking of writing software to do something along these lines.

    In particular what I'm looking for (and maybe other people are too), is a file system where it's easy to find files. I don't mean finding them by the name, but by content, and not just text, but graphics, executeable, you name it. For example, I have tons of pictures from my digital camera, scattered into different dir
    • Yes it is cool, but in version 1 you have to take on an enormous risk - virii, bugs, other issues crippling your entire OS is a more sophisiticated way than you can conceive a defense against. The more complex the system the more complex the attack. MS users do not require such complex systems - I don't know why MS is risking exposing them to more sophisiticated attacks.
    • Now, admittedly, this would also add on some responsibility to tag keywords to the files, and I've thought of ways of doing that as well (for example, applying keywords associated with a directory automatically to files placed in the directory).

      Of course you'd have to do that scut work for any of these FS's to be useful. Now if you've gone to the effort of making the directory meta-data useful and explanatory then wouldn't just walking the directory tree accomplish the same goal while being less complex
    • Now, admittedly, this would also add on some responsibility to tag keywords to the files,

      And this is the point where it will fail. Look, the concept is nifty, that is true. However common users rarely bother to give a document a good name, so why would you think that they are going to fill in the metadata? (Which you can do by the way in Office documents)
      Now imagine this: we are in 2006, you have your digital camera and come home from a long vacation. You want to upload the pics to your machine

    • There are plenty of tools for indexing and searching your disk; that stuff shouldn't go into fhe file system.

      I haven't worked out all the kinks, but to me, being able to find stuff quickly in file systems that are continually growing would be a huge bonus.

      Well, duh: that's what UNIX is all about. That's why you have dozens of command line tools to search and manipulate files with. For example, to find all TeX files in your home directory containing a keyword, use this:

      $ locate .tex | grep $HOME | xa

  • "NTFS does what it does incredibly well."

    Which is what, exactly? In my experience, NTFS has been nothing but slow, unreliable, and utterly unscaleable. Ever try running an NTFS volume as a cache or some other-small file storage device? Utterly unuseable.

    So if WinFS is to augment NTFS, my prayers go out to you Windows administrators.
    • Which is what, exactly?

      Easy:
      • Require frequent hardware upgrades to make up for its inefficiencies.
      • Keep competitors and OSS from being able to access data on Windows partitions reliably.
      • Keep software companies selling backup and file system maintenance software in business.

      It is really good at all of those things.

  • feh (Score:2)

    by syle ( 638903 ) *
    More like the holy grail of buzzwords.
  • your 'holy grail' turned out to be filled with urine?
  • According to sources close to industry experts, a new filing cabinet will be brought to market sometime in the next year or two. Instead of having files, labeled with what their contents are, you will have a master file cabinet, with thousands of records that will give you a map on how to open a drawer and decipher a complex set of instructions to find the paper you're looking for. The system will revolutionize the way papers are stored in folders. Previously, there was no large, cryptic system for shuffling papers around, now there is a standard way to misplace items. No longer will you have to look just in drawers, but you may not be able to even find the cryptic instructions to lead you to the drawer to start looking in. Details are sketchy, but some have eluded to possible bookworm attacks, that could corrupt the cryptography and therefore render your whole filing cabinet useless. Industry experts suggest that an anti-bookworm product could be available shortly to help protect from this.
  • While I applaud new thinking from any OS vendor, this type of re-architecting will mean little to the core home/business user. Are files really that hard to find on your computer? Are people really ready to throw their data into a virtual bucket and use pattern matching to find it later? Maybe, but consider the risks:

    1. It is discivered to be broken shortly after release. This would cripple the entire OS and require a huge mae culpa from MS.

    2. It is insecure. Once again, the whole OS would be undermined, us

  • SQL is just a corruption of the relational model, loosing power and simplicity. XML is just markup, and perhaps a nice programming convenience, but attempts to force feed it into databases and filesystems are bound to fail as miserably and costly as the similar attempts to force feed OO.

    On the other hand, even SQL would be better than the current hierarchical file systems. And a truly relational database system such as Alphora Dataphor as a filesystem would be my technical Holy Grail, yes -- just not in

  • Well, it isn't, but the overhead of such an inplementation has to be balanced with performance. NTFS is already fairly high overhead. I would rather see a small NTFS OS loader partition that initializes a main database partition. That way, there wouldn't be the overhead of NTFS on the main partition. I would hate to have my media library stored fully in NTFS and described by a database. It would be no different than using a modern media player.
  • In other news today, Microsoft announced the successor to WinFS, which is slated to appear in Windows LT(Long Tool) in 2012, BuzzwordFS. BuzzwordFS will not replace WinFS, it will incorporate features of WinFS, as well as every other possible TLA used in the computer industry, for complete buzzword compliance.

    • Beos poineered the FS as a database concept a long time back
    • ReiserFS already does these things (incorporating metadata into the FS), and does it extremely well (performance wise)
    • If Longhorn implements an intelligent FS it would be a good thing for *nix users as well who would otherwise have a problem transferring files/archives to/from windows machines.
    • The big question is not technical feasibility and not even backward compatibility. Its how to avoid chaos among developers. FS with metadata is such
    • Right now, filesystems store data as big blocks of bytes with some extra metadata on the side. Even Unix-likes have UIDs, permission bits and so forth. Storing arbitrary metadata or RDBM-style data is an interesting progression, but you're screwed once you try and transfer that data elsewhere over typical channels - like a simple HTTP transfer.

      The typical solution is to use OS-specific archiving tools (like tar) to handle the transfer of that metadata. But, for example, would you really want your audio

  • Complete this sentence: (Score:5, Insightful)

    by ivan256 ( 17499 ) * on Friday October 17, 2003 @10:30AM (#7240061)
    He goes on to describe such a filesystem as the 'holy grail' that is sought by developers... ...of high end processors, memory manufacturers, and name brand PC makers, who's sales have been down lately due to current software running well enough on previous generation hardware.
    • Very true. Hardware and software developers have a very symbiotic relationship. It use to be games that drove PC hardware sales, but that's started to change recently. High-end equipment from over a year ago is *still* fast enough to run the latest Windows OS as well as the most demanding games out today. (An AMD XP 2000 w/Radeon 9700 is still overkill for 75% of new games.)

      Someone has to pick up the slack and MS seems to have grabbed it with both hands (they already had the right hand on it.)
  • "Holy Grail?" Maybe Pandora's Box would be more apt.
  • This is a great idea in theory, but the fact is for most people simple == good enough. This thing is sure to be a real tricky thing to use at first, and it will take ages for apps to support it probably. For most people it will be pure bloatware.

    On the other hand, maybe Microsoft will pull a beauty out of the hat.... Naaahhhhhhh.

  • M$'s real holy grail (Score:3, Insightful)

    by smartin ( 942 ) on Friday October 17, 2003 @10:34AM (#7240104)
    And of course WinFS will provide them with the ability to enforce DRM down to the file system level. Which is the Holy Grail of squeezing every last penny out of your customers, and making exclusive deals with evil associations.

  • MS Filesystems are Internet Enabled!!!! (Score:5, Funny)

    by zulux ( 112259 ) on Friday October 17, 2003 @10:42AM (#7240155) Homepage Journal
    In 1997 Microsoft made a pledge to Internet Enable all of their tehcnologies - and true to their word, even their file-systems are now internet enabled.

    It's really easy to administer. Just plug you Windows computer into the internet, wait for a few minuits for a helpfull worm - and PRESTO!!!

    You file system is on the Internet Baby!!!
  • "He goes on to describe such a filesystem as the 'holy grail' that is sought by developers"

    And i thought AI was the holy grail! Damnit!

  • But...I like NTFS! (Score:3, Insightful)

    by NineNine ( 235196 ) on Friday October 17, 2003 @10:49AM (#7240217)
    NTFS has been an excellent FS for years! It's fast, it supports massive drives and massive quantities of files and directories, and it's incredibly fault-tolerant. What's wrong with NTFS?
    • What's wrong with NTFS?

      It doesn't force people into functionally unnecessary upgrades which keep MS profits high, that's what's wrong with it.

      "Microsoft - We force you to upgrade because We Care (about our profits)".

    • NTFS has been an excellent FS for years! It's fast, it supports massive drives and massive quantities of files and directories, and it's incredibly fault-tolerant.

      Yes, compared to (V)FAT, it's a great file system. But don't worry, Microsoft is trying to give you that old DOS feeling again by adding ample new opportunities for data loss and performance bottlenecks.
  • a filesystem which, accoring to Microsoft, will open up a whole new world of information availability. ... for virus writers, spammers and crackers, that is.

    No, I am not trolling. I am not even being funny. If Microsoft cannot reasonably secure their OS, what makes you think they will be able to secure this new file system?

    Think about the possibilities: no Admin password on this Windows 2020 box you just r00ted? No problem!! Just do the following SQL request and you'll find the password in plain text in t
  • I mean, yes, it certainly is nice that Microsoft is managing to implement this specific OS feature before Apple or the Linux community does, and they should get a gold star for Super Effort, but still.

    If this were the "holy grail", wouldn't people have cared a lot more about it when BeOS did it ten years ago?

    I find it amusing Microsoft has now for years been harping on this one SQL-drive feature in an OS that keeps getting pushed back and back. I guess it's because it's the only thing Microsoft has done i
  • "...all into a filesystem which, accoring to Microsoft, will open up a whole new world of information availability."

    Seems like with all the worms and viruses out there that Microsoft has already achieved this goal :)
  • Let me the first to turn the obvious phrase of 2005.

    BSC like BSD has a nice ring to it.
  • There are many things for which MS can be blamed, but one of the more powerful criticisms is that they have never done anything "truly wonderful" with all their power.

    I think this File System idea is just another example. Everyone talks about a "new" file system as if adding a relational database (of some kind) or meta data for the existing concept of file is somehow revolutionary.

    Why not try more radical ideas. We have a document style that is based on a generic "template" some of the document is the s

  • I've already got one and it's very nice!
  • It's the Holy Grail for developers.... Maybe the developers should learn to organize their files better. This is just going to lead to sloppy programming proctices and lazy programmers. "Why keep the files in directories that make sense when all we have to do is search for them?"
  • was pre-empted by the Windows Security Development Task Force. Now that they've handled things, everyone has access to everyone else's data.
  • I like how 99% of the replies to this article are negative or uninformed. We're really delving into the land of the SlashDot, aren't we?

    "It will be horribly slow!"
    "It might be insecure!"
    "NTFS is all we need."
    "LiNuX R000lZ!"
    "MS SQL is stupid, mySQL is better!"
    "XML is dumb, no one uses it."
    "In Microsoft WinFS, the files database you!"
    "Imagine a beowulf cluster of these.."
  • Well, this does not have to mean what most people here seem to think.

    What the article says is: WinFS will use the "querying capabilities" of SQL Server and the "data labeling capabilities" of XML. Now, put this into context. It does not neccessarily mean that everything will be stored as XML. I imagine it could mean something like this.

    Think of a directory as an SQL table, where the file name for each file is the primary key. Other metadata for each file, such as size, timestamp, priviligies can be thoug
  • If Wintel succeed to ban Linux and Open Source, Longhorn will be swiftly introduced, Palladium and DRM are implemented in hardware, and all people who are cought running Linux will get to state federal prison, as cheap labour.

    Next data recovery will become a enterprise class only service, which will cost fortunes. People might start loose data on their PC's as frequently as today BSOD screens popup. So next Wintel strongly suggests to put your valuable data on their subscription storage sites.

    Robert

  • Read the summary, even. I see a lot of people here complaining about NTFS going away -- it's not. WinFS is being built on top of NTFS, such that the underlying filesystem can still be reached.

    Think about it: It doesn't make much sense to move (for example) the kernel and other low-level files into WinFS because (a) it raises bootstrapping issues (in order to load the kernel, you'd have to bring up the database engine, but the database engine depends on the kernel) and (b) they don't contain much, if any,

  • What can WinFS accomplish that couldn't simply be done through filename conventions.

    For example:
    My Word Doc.doc
    My Word Doc.doc.xmlannotations
    My Word Doc.doc.sqlindexedtextversion
    My Word Doc.doc.xmlenterpriserelevancy

    together with a bunch of services that monitor, and assist in generating, querying, and interpreting the data.

    MS may be providing tools to assist in all this, but isn't this a very simple idea that can be done/copied with any existing OS, with little effort?
  • I don't get it. How is WinFS any different from indexing files and storing the metadata in a database, a la slocate but with more metadata?

    As I see it, if an app that doesn't know about WinFS, say a legacy app (or open up its data storage to WinFS) goes to store data in WinFS, it will ignore most of the metadata layer, and store its data as binary, whether that's as a BLOB in a DB or a file pointed to by a fs tree seems immaterial. This says to me that the main problem is that apps don't TELL each other
  • WinModems, WinPrinters and now WinFS.

    The first two were such huge innovations I just can't wait for the next one.
  • How long has Microsoft been working on this now? It's not going to happen. WinFS is fighting against entropy and human nature. It's going to lose.

    The moment you enter meta-data it becomes stale. Unless the meta-data is derived from the data itself, it cannot and will not stay synchronized without manual intervention or diligent application coding.

    If the application is responsible for maintaining the tags, only standard meta-data fields can be used or applications will not interoperate. Can we expec

Slashdot Top Deals

"...a most excellent barbarian ... Genghis Kahn!" -- _Bill And Ted's Excellent Adventure_

Close