because i tought it wasnt included in vista and moved to a later version of windows

It's possible, although Microsoft haven't announced it.

no it won't be because it doesn't exist under that name anymore. but anyway it won't be, apparently it wasn't as good as everyone seems to think it would be.

the good parts of the technology have already been implemented anyway.

I do think it's about time Microsoft designed a filesystem that dosnt have all the fragmentation issues that the current NTFS platform has. Both HFS+ and EXT3 are shining examples of this yet Microsoft is falling behind big time

No, from my understanding WinFS has been scrapped. I think some of it's underlying technology might of found it's way into SQL Server but that is it, it is no more.

I thought alot of the functionality was included in Vista anyway but it wasn't released as a single product as winFS was going to be. Don't know if parts were implemented in .Net or any of the other technologies. As for the file system comment above, maybe they do need a new file system but WinFS was never going to be one so it's not really a loss in that regard.

many parts of WinFS made it into different projects, but WinFS as you know it doesn't really exist anymore.
@ +Vegetunks WinFS would have nothing to do with file fragmentation as it was not it's a file system anyway.

except that winfs was not a file system but an additional layer on ntfs. And while NTFS has it's disadvantages it is still one of the best file systems out there that keeps getting improved with every version of NT. Like for example transactional NTFS in vista

Neither HFS+ nor EXT3 are shining examples of anything compared to NTFS.

Most of the important 'modern' features in HFS+ like journalling, storing tiny files right in the lookup table, and ACLs were added as afterthoughts, and this leads to it not being a particularly 'clean' setup. Also HFS+ doesn't support encryption, quotas, sparse files, or compression.

NTFS 15 years ago had all of the stuff HFS+ has today and then some!

ext3 is similarly primitive compared to NTFS. It's basically just ext2 with journalling. There are much better filesystems for Linux.


Also, WinFS was not a filesystem. It was basically a big database.

http://en.wikipedia.org/wiki/Winfs#Development

Just another thread proving that most people just don't understand what WinFS was and what it would mean.

In theory it is a great idea, but I don't think it would really be that practical as most people don't tag files to a good enough level to actually get real value from having it.

Much of its purpose was to replace files entirely for certain applications. All of the 'tagging' and metadata stuff can be easily handled by the indexer. We don't need WinFS for that.

i read somewhere MS might sell it as an addon of some sort separately

But for the rest, we would have to be much better at tagging files so that we could find them with WinFS, or at least better than we could with the hierarchical view we currently have on file systems.

But again, to do that kind of stuff you don't need WinFS. The indexer and explorer could handle that aspect as well, if not better.

It wouldn't really take much to cut down or pretty much "fix" the fragmentation that NTFS has if MS takes a proactive way of writing data like some unix/linux FS's do. Before data is written to the HDD the FS looks and tries to put the files in order so they don't fragment. It's like defraging before you write instead of doing it after in the background like Vista does it.

I'm sure if you look at UFS you'll get a good example.

WinFS as I understand it was more a developers platform than anything a consumer would notice. A good example is the windows search which was to be tightly integrated with WinFS. Despite WinFS not being there that doesnt change the end users experience in the slightest. They can still tag, choose not to tag ect, it's all application dependent. WinFS would not have removed the hierarchical file structure at all, as stated it ran ontop of NTFS therefore it wouldnt remove functionality there already but run in addition to.

Furthermore as mentioned above alot of the functionality of WinFS has been ported over to other projects. As far as I can see it the loss of WinFS was greatly exagerated partly due to Microsoft over hyping the feature. While good for developers I don't think end users really were effected either way nor did they ever know what it was anyway based on how many ppl think it's a file system. Developers still got catered for via other means.

Did you actually read what I wrote, here it is again with the appropriate part in bold:
But for the rest, we would have to be much better at tagging files so that we could find them with WinFS, or at least better than we could with the hierarchical view we currently have on file systems.

I too think it would have had no real, tangible benefit on most users. I guess we're all saying, "Who cares"
I had no idea that HFS+ has fragmentation countermeasures. Does Vista really defrag in the background??

I think NTFS (or Vista) partly does that already, although not as efficient as linux or mac file systems do.
It tries to put huge files in large free space parts of the disk - not like with FAT or FAT32 where files are written to the first empty block, no matter how small it is.

Besides, I hardly get over 1 - 2% fragmentation in Vista really

@WinFS: I thought BrandonLive once said something about it. That it was "an experiment that didn't work out". I'm sure he can explain it better than me.

OK, found his post:

As I said: If explorer goes to the index, it can take care of all of that. Look at Search Folders, and the various grouping techniques Explorer offers that all rely on the index. You can get all of that functionality, and anything you're missing with regards to file tagging can be added by improving Explorer without WinFS.

WinFS has more or less "shipped" or will "ship" soon, although not in its original form:

LINQ
ADO.NET Entity Framework (this and LINQ help developers work with disparate data types and sets more easily)
SQL Server 2008 support for filestream blobs (aka storing files inside a database)
Windows Desktop Search (fast, file-content search)
Microsoft Sync Framework/Live Mesh (syncing)
Windows Backup (backup)
Stacks and Saved Searches (stacks and virtual folders)

What we're missing is the shell integration, which Microsoft deliberately backed away from during Vista's development as it was proving too confusing to users at that point. From the screens we've seen of 7, they are slowly moving back in that direction. We're also missing the various schemas for built in types, but that's not really important to the end user anyway. You also technically lose querying, but the search feature is robust enough that it shouldn't really be a loss to users. I can still, say, find all pictures taken in London by Johnny on December 17th if I wanted to through WDS.

Fragmentation would not have been improved by WinFS as many have said, because it wasn't a file system; in fact it may have been worsened because every file would be stored in large database files. Microsoft has helped mitigate the fragmentation problem by scheduling a defrag by default in Vista, but in a few years fragmentation should be a worry of the past anyhow thanks to SSDs.

I still wonder why is it so over hyped by people who haven't even touched it yet...

Hopefully it will be included ...

By default in Vista the built-in defragmentation service/system w/e is set to work when your system is idle if it needs to. I don't know if it checks first or if it just goes ahead and defrags the newest data written for the day etc, but that's how I remember it being set.

NTFS is much more modern / clean than HFS+ or Ext3. If you want to compare it to something, compare it to the basically dead ReiserFS project or to ZFS.

Fragmentation is a problem that will start to solve itself with solid state disks. Besides, it's better to defer the defragmentation process until idle time, rather than proactively doing it at write time (which slows down write performance substantially).

never mind...

Really? Write times are perfectly adequate here.

On-the-fly Defragmentation only occurs in the following instance:

When a file is opened on an HFS+ volume, the following conditions are tested:

* If the file is less than 20 MB in size
* If the file is not already busy
* If the file is not read-only
* If the file has more than eight extents
* If the system has been up for at least three minutes

If all of the above conditions are satisfied, the file is relocated -- it is defragmented on-the-fly.

OS X/HFS+ have built in counter measures to stop defragmentation for happening the first place though: http://www.kernelthread.com/mac/apme/fragmentation/

Could be useful, I'd just like to add here that WinFS wasn't a file system on that level. WinFS ran on top of NTFS and thus suffered from the same fragmentation issues that plague NTFS. The intention was not to fix this either with WinFS, but to build a more object-oriented file system better uncoupled from the hardware / network to the end user, e.g. replacing the typical hardware-related volumes with abstract "storages".

On the object orientation topic, I think Windows PowerShell looks interesting there. There, you manipulate each file, directory, or volume, as an object with various properties, and can do actions on them in scripts. Something that separates PowerShell from CMD and even most Unix shells like bash, ksh, zsh, tcsh, etc.