Slashdot Mirror
Tom's Hardware Looks At WinFS
Alizarin Erythrosin writes "Tom's Hardware Guide has an article about the new WinFS file system. The article talks first about some of the problems and advantages with FAT[16|32] and NTFS, then talks briefly about WinFS. Here is the summary: 'Microsoft is breaking new ground with Longhorn, successor to XP. The upcoming WinFS file system will be the first to be context-dependent, and promises to make long search times and wasted memory a thing of the past. Today, THG compares it to FAT and NTFS.' Personally, I still have reservations about using a relational database to keep track of files. Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be."
yeah, but you still get a choice--i don't use mac os x's journaling because of the overhead--you don't hve to use winfs if the performance penalty is too high.
----
http://www.hellection.com
Now that every Windows user is going to be running a SQL variant on their system, imagine the bugs and holes that are going to be in this. Now THIS will be interesting to see.
Fundamentalism stops a thinking mind.
Although I do take issue with the discussion of NTFS. Where's the references back to HPFS?
God - I remember hesitating going up to FAT32 - I had only just gotten win95 and it was nagging me like hell. Then I was nervous about upgrading to NTFS, then discovered how horrible it was not being able to use a drive with anything but WinXP. I have a triple boot with WinXP, linux and win98SE Really, there's no difference between the file systems for the normal user! Why upgrade when it doesn't make your life any better and it takes alot of bother and reduces compatibility?
BeOS used indexing for certain attributes, and it is GREAT. Maybe someone is just sour that linux didn't do it first?
It just can't be good. Using MS SQL as a database is bad enough, I couldn't imagine depending on it as a file system.
You'll have that sometimes...
Wasn't this supposed to be an SCO story? We're falling behind our quota today.
In any event, Microsoft still has a few years to refine this "Future Storage" file system, so all judgements concerning it's effectiveness are a bit premature on some levels. Then again, it's always good to start planning as early as possible - especially when you consider that it may be introduced into Windows Server 2003 some time during the next 12-18 months. For now, all we can base judegement off of is Microsoft marketing hype and comparisons to existing file systems that operate in a similar way.
A relational database setup should do wonders for file search and access. Most filesystems today weren't designed with 200 Gb drives and millions of files in mind.
I keep thinking back to my Amiga when a 40 Mb hard drive was huge. Hell, I have a keyfob with more storage space now! Can you imagine AmigaDOS (not FFS, the old, slow one) on a 200 Gb drive?
Learning HOW to think is more important than learning WHAT to think.
Will it boast features that ReiserFS and other Linux filesystems provide, such as losing my data and corrupting the filesystem?
This article is bullshit. There isn't a shred of new information in it. It's like watching CNN.
In Soviet America the banks rob you!
This whole idea came to me in a dream a few months ago. I can think of many cases where SQL based filesystems would have serious performance advantages. It's not for everybody, but for some applications it would be great.
I Geek
Haven't they basically been trying to implement this since the days of Cairo? Seems the 'revolutionary new file system' gets announced for every Windows release that is several years away, then vanishes by the time the release takes place.
.technomancer
The upcoming WinFS file system will be the first to be context-dependent, and promises to make long search times and wasted memory a thing of the past.
Well, yes; we must preserve those system resources for the most recent incarnation of explorer.exe.
Do you like German cars?
This will be better than FAT32 and NTFS, but it is hardly "breaking new ground". A number of operating systems have used more-or-less relational databases as their file systems; it's a special purpose technology and has no place in a general purpose OS. I think ReiserFS makes the right kind of compromise here: it uses a little bit of database technology, but it mostly remains a traditional file system.
I find that 4gb (or is it 2gb?) file size limit rather annoying when doing video stuff.
see subject
The performance is the most important thing to the WinFS I think. I hope it could be faster than NTFS.
"Personally, I still have reservations about using a relational database to keep track of files. Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be."
And, of course, this author is qualified to pass judgements like the one listed above. Please.
Exactly how efficient should a file system be, genius?
From the article:
"The folder structure shown in the Windows Explorer is thus reduced to a virtual map. Directory structures provide some guidance but do not say where data is actually stored, how the system organizes files or the nature of any data pointers stored with them."
In my miserably unprofessional opinion, obfuscation of the allocation tables in favor of virtual maps that are more user defined or, bettter yet, dynamic, learned content organizations are what the file system should be.
But I already qualified my opinions with the statement... "I don't have any idea what I'm talking about".
That would most likely produce problems for multi-boot systems, since the only way Windows XP, Longhorn and Linux would all be able to access one and the same volume would be through complex methods - if at all.
So I will not be able to access anything on my Windows partition from my Linux partition. How about the other way around?
As far as i was concerned, WinFS was not actually a real file system but something that just runs on type of an NTFS filesystem.
This was actually confirmed at WinHEC:
"Microsoft has scaled back its 'Big Bang', and its Future Storage initiative will build on, rather than supersede the NTFS file system, when the next version of Windows 'Longhorn' appears in 2005."
"WinFS is not a file system
NTFS will be the only supported file system in Longhorn, from a setup and deployment standpoint, though the OS will, of course, continue to support legacy file systems like FAT and FAT32 for dual-boot and upgrade purposes. The oft-misunderstood Windows Future Storage (WinFS), which will include technology from the "Yukon" release of SQL Server, is not a file system, Mark Myers told me. Instead, WinFS is a service that runs on top of--and requires--NTFS. "WinFS sits on top of NTFS," he said. "It sits on top of the file system. NTFS will be a requirement."
Interestingly, when WinFS is enabled, file letters are hidden from the end user, though they're still lurking there under the covers for compatibility with legacy applications. This reminds of when Microsoft added long file name (LFN) support in Windows 95, but kept using short (8.3) file names under the covers so 16-bit applications would still work. Expect this to be the first step toward the wholesale elimination of drive letters in a future Windows version."
It sounds interesting, to say the least. Maybe Microsoft has finally come up with something innovative. I'd be interested to try it out and see how it feels, and if it really can do everything they say it can. As usual, though, security could be an issue. A virus could wreak havoc if it found a way into the database.
Also, I'm wondering if they'll finally give up on that stupid drive lettering. I don't see any reason why that ever had to exist, and now that they're doing an overhaul of the whole filesystem, it seems like a good oportunity to get rid of it. You'd think, since they try to be user friendly, that they would want to give devices and partitions names instead of letters. I do still see it in that screenshot, but things could change by the time it's released.
Once Microsoft integrates a relational database into the operating system, worm penetration will reach 100%.
Seriously though, I hope they port the registry over to a real database system along the way.
Longhorn will include a database-like file system called Windows Future Storage (WinFS), which is based on technology from SQL Server 2003 (code-named Yukon).
I guess now we have to worry about Slammer and CodeRed style attacks on our file systems as well?
LinFS based on MySQL? lol.. no MySQL is lousy piece of junk. Sorry. If Linux desires to have similar file system support as in Yukon, it needs to start from scratch. MySQL is not the way to go.
down to a -1 troll when Michael sees it. Mark my words
AmigaDOS had an 80 character or so comment field for each file. The comment didn't show up when you did a DIR, but when you did a LIST it was there. All of my pictures and sounds had nice descriptions in the comment, size/depth/mode/etc.
Very useful.
Watch for patents that prevent any kind of interoperability. You though being tied into a document format was bad.
Just imagine dealing with the current MS filesystems without third party applications. Ha!
This article is tripe.
The closest it gets to examining the (possible!) new Windows filesystem is calling it a relational database, and going on for a bit about how paths (ie: directory structures) will be irrelevant. Oh, and yeah, the closest thing he found to the implementation was called "winfs.exe" and did nothing but produce errors.
The bulk of the article is a (poor) attempt at explaining filesystems in general, and FAT and NTFS in particular. However, it gets a number of things wrong and - at best - garbles a lot of things. If you already know what he's trying to say, you *may* be able to pick out truths, but if you don't you'll walk away with misinformation.
I would suggest instead perusing arstechnica.com and aceshardware.com. I don't know if they've done any filesystem stuff, but if they have it'll be of reasonable quality.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I read this article hoping for some real information on the WinFS file system, and instead I got an amature's review of Microsoft file systems I grew up with.
"There has been much speculation"
Uh huh.
"Win FS is modeled on the file system of the coming SQL server"
Uh huh.
"In its latest build (M4), Longhorn contains few hints of the technology's imminent implementation."
Uh huh. You're saying you don't know anything, yeah, I'm getting that part.
"One of those is more than 20 MB in size and bears the name winfs.exe."
Neat.
"In the end, Win FS will probably emerge as an optional file system beside FAT and NTFS. It's also possible that Win FS will supersede its predecessors, however."
So in the end, it'll be A... but it is also possible it'll be B. I see.
"That would most likely produce problems for multi-boot systems"
An astounding feat of logic Mr. Spock!
This is the most uninformative article I've ever had the displeasure of reading on Tom's Hardware. These people know exactly nothing more about WinFS than any of the rest of us have heard in rumors and vague press releases.
His post is darn insightful, wish I had some mod points :-/
100% Crunchier
How about Clippy? "I see you're looking for your work files. You're fscked."
One line blog. I hear that they're called Twitters now.
The Nautilus process uses 90 MB of RAM when it runs. 90 fucking megs!
Looks like I was wrong - or, actually, right all along. Musta been a slow news day?
It's really irritating to have a RAID that gets crippled to 5-10MB/sec when on other OS and FS combos it can do 80-100 because MS has decided "Oh performance isn't important, reliability is, so we'll force cache off for all SCSI miniport devices even if it says it's on."
f =2&t=1758&hl=slow+scsi+performance&s=9f0e65a3ff482 2032e4a63091694cc3f it never got fixed. Non-RAID IDE is unaffected supposedly due to a "bug" in the system where IDE devices ignore the OS commands to switch to write through caching. It's really ridiculous when a 700MB file takes almost 2 minutes to copy under XP and yet under BSD on the same system dual booted on the same array, it takes 11.2 seconds.
See http://forums.storagereview.net/index.php?act=ST&
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
XFS would already be a prime target for doing this in Linux and I guess on IRIX too. XFS has can store attributes, which one could add the MIME type and maybe even some small like up to 128byte descriptions to it. Actually someone, not using XFS though, added something to KDE to do this. It was on /. a few months ago.
NTFS has tons more advantage than FATxx. The official list can be found here. Granted, this benefits the corporate user more than home user.
At the very least, NTFS offers a quicker way to hide porn than FAT32.
I have a feeling that MS will do it half-assed, just like always... and in that respect I think winfs will probably suck, however if done right, it would rock.
The concept of naming files, and sorting them in directories isn't a very good concept, and the proof of it is looking at how everyone here uses playlists to handle media files.
None of us even know the filename for our mp3s anymore, it's buried in iTunes or Winamp or XMMS, we just know the artist, and the song name. As a side-effect, we can easily find songs by the same artist on our harddrives, or same genre.
This obviously doesn't require a database filesystem, but I think it's gotten to the point where we *need* some way to assign metadata to files and then deal with files *soley* by metadata.
I think filesystem creators could take a huge hint from Content Management Systems. CMSs are more powerful than filesystem, and much easier to use, especially when dealing with a huge number of files.
Hopefully this will encourage more competitors (including open source) to go for the RDBMS-based filesystem model.
I don't understand the concerns of the poster regarding performance (at least without evidence of truly dismal performance): no one is forcing anyone to use the FS if they are not satisfied with performance.
For most users, they main bottleneck in storage is their own organizational faculties. I used to be exasperated when users didn't know where they put their files, but once you get past the 100GB mark, it becomes very understandable.
Consider what most people use their massive storage for these days: videos, music, multimedia, games. Not only is this the kind of content that SHOULD be stored in a database, it's the kind of content that is ALREADY being handled through a database because the filesystem is not enough: people are using their media players, P2P programs and other software to handle their files, up to the point they rarely ever interact with the filesystem unless they lost a file.
For most users, the performance penalty is well worth the price.
For those for whom it is not, it doesn't take a genius to realize you can use more than a single filesystem, and perhaps rediscover the joy of proper partition organization: keep the OS and applications separate from your data, and you can use your highly efficient filesystem for the first and your metadata-loaded one for the second.
Freedom is the freedom to say 2+2=4, everything else follows...
Could this be a first for Slashdot? Trolling for flamebait?
No, his post was completely uncalled for tripe. It's fuckign flamebait.
Microsoft thinks they are all that but Mirror Worlds Technologies beat them to it. Try scopeware vision for win2000 and xp. scopeware vision. It can index and search your ogg vorbis files. It also has way cool views written using SDL. There's a free trial available on the web page.
1) NT4 (certainly from SP3) allows you to make partition alterations without a reboot. Even 2K requires a reboot for alterations to the boot partition, however.
2) 2K doesn't dispense with the drive letter concept, despite the implication in the article that this is the case. That you can mount partitions under folders doesn't change this.
3) You can specify the cluster size when formatting a drive under NT4.
Also, has anyone actually come across a data centre that is making use of multi-hundred-TB NTFS volumes?
And, will Longhorn finally do away with the whole drive letter concept?
"God, root, what is difference?" - Pitr, userfriendly
Relational databases are better than conventional file systems in both performance and transaction management/journalling.
However, the best solution is that used by EROS, which is for the kernel not to provide a file system at all, but instead provide Orthogonal Persistence.
This is a much simpler layer for applications, since it doesn't require them to explicitly access the memory and disk separately. It is also much simpler to recover from because the entire state of the whole disk is always known to be coherent with itself at all given points in time, without an expensive journal.
In terms of performance - it beats the hell out of explicit disk access systems (Both conventional and database systems) because it performs big continuous reads and writes (that don't move the head much) rather than small writes on metadata and file data that forcibly jump the disk head around.
In EROS then, on top of the Orthogonal Persistence, you can create any arbitrary Objects you want easily - because they're just normal processes with normal memory. Conventional File Systems become useless and objects implemented by processes become a much better and more powerful alternative to files.
A relational database of the user objects is then much more powerful than a string hierarchy, but this is all the user's choice - and not hardcoded into a kernel.
Personally, I still have reservations about using a relational database to keep track of...
Don't tell that to your brain, you might be forced to go to summer school...again.
I'm looking forward to this! I personally am sick and tired of filesystems as we know them today. Today's filesystems are a strict hierarchy, the existence of which is only necessary in the systems of yester-year.
:+) Maybe the initial implementation wonâ(TM)t get all this right. But at least it stands a chance.
A filesystem based on a relational database will have some characteristics to which today's filesystems can only aspire:
1. ACID - In every way that the underlying database supports Atomicity, Consistency, Isolation, and Durability, so now will the filesystem. In so far as the database is robust, the filesystem will be robust. Please spare me the comments about the supposed unreliability of SQL Server. Itâ(TM)s certainly more reliable than NTFS; which is itself very good.
2. As an offshoot of the above - Imagine multiple file updates to a filesystem which is transactional! Imagine that transaction failing and being able to just rollback the changes without touching every file in your program! Imagine being able to make file changes programmatically without having to worry about locking because the engine will do it for you (just handle any exceptions)! Yeah, you could do all that today if you like. But it takes extensive to make it happen.
3. Operational characteristics - We can run queries against databases. We can index them. We can cluster them. We can replicate them. We can access them easily from any development platform you can imagine. Now your filesystem is a database. The possibilities make me shiver!
4. Another offshoot from #3 - Security. Databases are inherently better than filesystems (IMNSHO) at enforcing security and enabling administration of security.
I only have reservations about one issue with the database as filesystem area: recovery. Currently, all good and low-tech filesystem recovery tools really are based on the filesystem allocation table sort of scheme. Obviously, databases usurp this category of tried and true tools. However, good tools already do exist that allow recovery of relational databases. Itâ(TM)s just a matter of getting easily accessible tools of this sort into the hands of professionals that need them. It's more of a training issue I guess, but it will still need addressing.
I know many people will have a knee jerk reaction to this idea, and I understand why. But I would encourage people to keep an open mind to this. While there will probably be some issues with the idea, there's so much more that could easily be done with a filesystem on top of a database than could be done easily (or well) with a traditional filesystem.
And for you hard-core naysayers out there, you have to ask yourself this: If this is such a bad idea, then why did Oracle provide this as a feature too?
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Near-Term: this thing should be just as stable as every other MS product prior to version 3.0 of it. (In short, damned lousy). To make it worse, it probably also enables DRM at a file system level...
Mid-Term: FS finally works, and allows easier retrivial by relevance, author, source, etc. in ways that we can just dream of now. It's the kind of thing we didn't realize we needed until we had it...until it inevitably blows up as all MS products must do eventually. But when it works, we will be fairly happy to have it...especially end users, most of whom can't figure out a hierchical file system in the first place.
Far-Term: FS is finally able to use it's relational roots to distribute filesystems over multiple processors in an cluster or over a network. Such a system would support atomic, distributed file updates by threads of processes on differing processors (including HyperThreaded procs). Imagine a virtual filesystem that can span your whole-house network, with a single file system image...in WINDOWS.
So I guess my view is: painful in the near-term, but may be cool to have when they get it right.
I'm a "normal" user (or at least more normal then most slashdotters I'm sure) and I use computers for the following things: Games, Music, School/University work, Internet. Perhaps watching the occasional DVD.
:)
Quite frankly, why should I, or any "normal" user, upgrade to a file system that doesn't make a difference to my everyday life? I didn't rush to upgrade to FAT32 or NTFS, and nothing in this article is convincing me that I should upgrade to WinFS. (infact nothing in this artice is saying much about it, but that's for another poster I'm sure)
I had another message about this, and was replied saying "what? There's many differences: in Fat16/32 you're restricted to 2GB/4GB files" etc etc.
My reply to this is that when I was using Fat16 it was with a 1.18 GB hard drive. I used Fat32 for a time with an 8GB (hard drive maker GB) hard drive, but why on earth would I have a file that took up more then half of my hard drive? The first time I ever had a file above 2GB in size was a few months ago with digitalised family videos (promise to mum
For upgrading to NTFS, I don't really care about gigantic cluster room. Why should I? I have an 80 GB hard drive filled to about 60 GB, so why should I care about one GB of this being filled with crap allocation tables? Since I can't have any OS before win2000 anywhere near it, say if I want to put my HD in another computer for example, the disadvantages far outweigh the advantages for me. I do have WinXP installed on another NTFS formatted hard drive but I'd prefer to keep the hard drive that has the majority of my important info as compatible as possible.
Now with WinFS, I'm probably going to put that on when I get another hard drive, but not before. There doesn't seem to be any point! I'm sorry to all of the video editors out there, but I really don't want to take the bother.
We, like everyone else, do not know anything about WinFS other than it will be possibly be used in Lognhorn, and will replace FAT32 and NTFS.
90% of the article was a completly different topic, how the older FSes work.
I'm working on a web-based relational filesystem that works to provide metadata using unix-style permissions as an overlay for additional security over the (1+) server's perms. If you're interested in working on such a project just send me an email to jobs@thinkingman.com. The project's called kahiko (hawaiian word). Mahalo.
Thinkingman.com New Media
Is there any open filesystem that operates in a similar manner?
I'm not sure exactly what you mean, but I'd say "all of them."
The way I understand it is that on Linux/unix, if you're using a file, it gets loaded into memory and then the copy of the file on the disk becomes completely irrelevant. Case in point: delete an mp3 while xmms is playing it; xmms will keep on playing it without any trouble. I've also moved/renamed files that were being actively downloaded by BitTorrent, and they came out fine.
and may I ask, how many people have 1000 40kb files on a hard drive let alone one that is 500MB in size?
So, as it seems, the Redmondistas want to re-invent the wheel again... Pick/OS = RDBMS for file system and BASIC as command interpeter, circa '70's to late '80's... Now we're looking at "innovation" for circa 2005, WinFS= RDBMS + "visual basic iterperepers" for the commands. But thats OK, DOS and and CPM in the '80's were a DEC OS from the early 60's...
I recently installed a Win2K server that is blindingly fast at finding documents and such... but horridly slow at serving up portions of files, for things like legacy database programs. Three of the customer's applications started running at 1/4 speed.
It got so bad, even after all the "fix win2k speed" patches, that we re-introduced the 200MHz NT4 server to feed the database apps, and the dual-processor 2GHz system just serves up documents!
Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be.
They may have goals other than efficiency. Security, probably. But probably also security's perverted uncle, DRM. As DRM becomes more common, and we "pirates" look for more innovative ways to get around it, locking us out of our hard drives would seem to be a logical if not downright necessary step. It's pretty obvious that a lot of entities out there would benefit greatly from a model where we don't really OWN our computers, we just lease the right to use them. I mean, look, they're already floating the notion out there, at least for software and entertainment media, that we don't really OWN ANYTHING, and it's not that much of a stretch for that to become literal truth, aside from the hardware, which will be as impervious to meddling as they can possibly make it. (You decide who "THEY" might be, but I have a long list with a lot of familiar names on it.)
How technically difficult would it be for, say Microsoft, to "rent" out portions of your hard drive to various media and software providers, using a combination of hardware and software controls to assure those companies that you and I ABSOLUTELY CANNOT meddle with "their" product while we (temporarily) posess it? A database-driven file system provides exactly the access control and accountability that would be required to successfully implement something like that.
To ensure perfect aim, shoot first and call whatever you hit the target
Nevertheless, the current file system they have is technically far behind any reasonable database.
As a matter of fact, it should not take long to create an Oracle-based file system...
That's probably more applicable than you intended: File System Check
While the article is light on details...
Oracle's been doing the "relational database as file system" for quite some time now with iFS.
Bah. Seems to me to be a solution in search of a problem.
I don't really know what you mean. You can move files anywhere and they should still work as long as the program you are using knows how to find them. Sure if you wanted to you could replace a normal file opening statement with one that did a search for the file using SQL or something similar. This isn't really a filesystem function.. it's just a layer on top of it. It'd work with pretty much any filesystem and a database. Programmers often employ virtual filesystems to work with such information. If the program supports it then it'll work. You will notice they said that WinFS will still provide a directory structure for files.. so that existing programs will still work (And users won't be confussed).
With any filesystem you don't really know where on the disk the file is being stored. Directories are really just some glue to make it easier to work with files. It works well because most information is heirarchal. Unix/Linux also makes it easy to create links. This is an easy way to provide multiple heirarchies for the same files.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
hi folks, I'm new to slashdot, but this is reall c001.
Geeks everywhere have been doing this already for a long time. It's nothing new or innovative. It's even been done in the filesystem code by several different groups (and that's still a bad idea). I've been doing this with Linux and MySQL for years. Once again Microsoft is trying to claim innovation on something everyone else was already doing.
On the other hand I wouldn't mind seeing a standard library for this purpose if one doesn't already exist. I know Gnome has a VFS library. I'm not sure how much of it is reused by other projects or who originated it.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
A directory tree is a very useful structure, at least to the software. Similar stuff is grouped together, and easily cached. It provides a very clean and simple way of putting data somewhere and getting it back later. This should not lightly cast aside.
So, you want to use a relational database to keep track of files? Go for it, but instead of keeping track of the files themselves, keep track of their paths. Let the filesystem do the efficient storage, and the database do the efficient lookups. The database can be made faster and smaller, the filesystems can remain as fast as they are, and the files are still there even if the database gets corrupted.
Put hooks wherever necessary to update the database when the filesystem changes. For example, put a database in the root of each filesystem. Use a stacked mount to mount that disk, so when interesting things happen, the kernel tells a userspace process that updates the database. Then, make some standard libraries that use the database. Make file browsers that can query it, but pass the path to programs. Make save dialogs that can also save metadata about the file, and open dialogs that can search for it. Use LUFS or FUSE to make directories that correspond to queries.
This is just as effective as what MS is doing, but it's more efficient, it's more compatible, and it doesn't reinvent the wheel.
Litigious bastards
Offtopic I know, but why is it that a .doc from OOo is a lot smaller than one from MS Office? I have a .doc from MS Word which is 47KB. If I open it in OOo and save as, its 31KB. I then open the 31KB one in MS Word and it is the exact same as the original. If I save that one it goes back to 47KB. Is it because MS Word saves user info in the .doc (right clikc the file and go to the last tab at least in Win2k, it shows your name, while the OOo doesn't).
So WinFS (Windows File System) Is actually Called WinFS FS (Windows Future Storage File System) Microsoft Does it again... didn't they have an internal debate about what CE and XP and NTFS actually meant?
fellas fellas, please don't feed the troll (classic, right? Even decided to mispell "Linux" and "Linus Torvalds", straight from the manual .... :)
.. --
Parent: This wasn't anywhere near subtle enough, I'm amazed that you haven't been tagged troll or flaimbait
A Mac desk accessory / extension combination, I believe, that came out in 1990 or so. It allowed you to instantly retrieve lists of file on your hard disk based on name and content (by "instant" I mean the list of matching files changed as you typed your query).
On my IIci it was perfectly fast. Faster than BeOS queries on a dual 603 box.
It took a little time to build your index, but keeping it up-to-date was pretty painless. Apple's developer CDs used to ship with On Location indices on them.
. . . that frothy mix of shit and lube after your boyfriend gets done reaming your asshole . . .
Did you know that stuff has a name? it's santorum! No kidding! Funny, eh?
To pull this back OT: the above-referenced article at THG has exactly as much new information on WinFS as the horrid post to which this is a reply.
Good day sir.
I said good day!
everything in moderation
Eh, what are you talking about? I just transfered a 700MB (movie) from one raid drive to the other (different SCSI controllers even) and it took less than 1 mins 10 seconds. I don't see why you are having this problem, is your controller a cheap one (promise?).
To enable write caching, right click on the HD device (not partition), then go to Hardware->Properties->Polices and make sure the tick mark is there (in XP Pro Corp).
Then at the end there's a few paragraphs with no real info about the FS at all. What meta info will be stored? How will the files be laid out on disk? Is there going to be journaling? How about file system integrity and recovery?
The only thing _really_ learned was that there exists a 20MB beta executable that doesn't do anything. What the frell? It's two years before Longhorn is to be released. (As if Microsoft is going to get it right the first time anyway).
Mod the whole article down. Way down.
Actually since it's just a metadata database index to the unerlying NTFS filesystem MS is kind of me-tooing, there have been linux implementation of this scheme using MySQL for ages.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
One interesting question would be, should this all eventuate the relational database filesystem that is. Does this then mean that the Windows "GUI" would then be a layer ontop of the database eg since the underlying filesystem is a database could third parties then create alternative "Window Mangers" for windows that hook into the "file sytem" This could be a good thing, stay tuned for MS selling "Coporate Desktop" and "Home Desktop" add ons for Longhorn
it doesn't involve insanely cryptic commands.
silly faggot, linux is for...uhm...faggots
New file systems always worry me esp with regard to data loss. With FAT and NTFS they are old but they are stable. I've never seen the OS lose data, though if there is a sudden crash then yes, but not during normal operation.
New FS = New corruption?
Rus
Cheap UK and US VPS
However, that would provide lots of scope for slashdot rantings about embrace and extend...
.haeger
While I agree with You that they'd have to extend whatever open/free FS they choose, I don't think that the "embrace and extend" would be an issue.
The GPL which both ResiserFS (I think) and XFS are released under won't allow Microsoft to pull any of that old shite. The GPL was designed with that in mind. Personally I think it would be great if MS would do this, anything to enhance and improve the open standards is good in my book.
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
It's every slashdotters dream to get a "Score:5 Troll" post.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
...MSWindows inches closer to where BeOS was 7 or 8 years ago.
Didn't BeOS beat MS in this regard. I guess what's old IS new again.
Umm... he said it took 11.2 seconds under BSD. While slightly over a minute is better than slightly under two minutes, there is a very large time difference between 60+ and 11.2 seconds.
Security is built in below the operating system. It does support an "integrated file system" that presents file paths other systems can understand for the sake of interoperability and portability of Java libraries.
-- All your bass are below two Hz
The first paragraph of this article is all over the shop like a mad woman's knitting. I particularly like,
Yeah right, coz that's where the physical memory is.
And this new filesystem is supposed to be good because you can search for stuff faster or something? Why not just don't lose your files in the first place and update your locate database daily and fuck I fucking hate those dirty monopolistic fucks and Redmond is hit by an almighty fucking asteroid and fuckety fuck fucking fuck.
Now wash your hands.
I've been reading and contributing responses to Slashdot for years, but this is by far the worst article I've ever seen posted here. I can't believe whoever posted the article on the "front page" of Slashdot actually read the article -- they couldn't have even read the first page.
Right on the first page of the article, the "journalist" who wrote it describes disk storage as "memory". In the "Summary" of the article posted on every page, current file systems are described as wasting "memory". This reminds me of every-day users who confuse their computer running slowly (or literally telling them they don't have enough memory) with the need to delete files from the hard drive -- two completely separate things in most situations. This is all aside from the fact that the article doesn't actually tell you much that anybody who's used computers for more than six months doesn't already know. This guy sounds like some of the kids who come to me interviewing for I.T. positions thinking they've got a leg-up on everyone else because they've got some basic experience with PC's and Windows.
The bottom line is that the guy who wrote this article doesn't have any business writing tech articles without heavy supervision from someone who KNOWS tech, and I don't just mean someone who knows enough to rattle off performance numbers for CPU comparisons (read some other articles on the site). Lastly, Slashdot has no business posting amateurish and misinforming articles like this for the rest of us to waste our time on.
Yeah, the filesystem that was already obsolete within a year of its initial release....
HPFS had a hard coded limit of 4G partitions.
And no amount of juggling could raise it.
That's why M$ ditched HPFS support in Win2K.
Very good attitude, quite refreshing on /.
Different strokes fer different folks etc.
The point is, MS seem to be looking forward, to the new users rather than trying to appease existing windows users. From what I've read, the new file system/structure seems pretty logical. Especially if you try and think of it as something other than a 'desktop file system'.
I look forward to seeing it develop. At least MS are trying to innovate.
Hmmm.
I have ~ 160,000 files taking up 55 gigs on my NTFS partitioned hard drives. It took over 5 minutes on my 1.6ghz machine to come up with that.
To search for a specific file often takes much longer.
Personally I look forward to a better, faster file system on Windows. Although I'd still hold off judgement of the new system until it becomes available.
-
Rod
I bet he used cp, if he was on X and used nautilus/KDE to drag and copy, it would have taken 1 min as well, cause of the filemanager caching/overhead and so on.
For a better benchmark he should have used XP's cmd line copy command.
With copy, I'm getting less than 5 seconds on XP Pro with RAID-5.
I noticed right clicking in Win Explorer in Win2K allowed you to apply attributes to files. Not sure if they were limited to MS Office files.(Sorry, I can't check this anymore ;-)
The metadata in database, files on disk is used frequently in any number of applications. Some search engines do it (at their heart, search engines are databases - just not usually relational). I've also seen email servers, document management systems that do the same.
Even good ole rpm does the same thing, doesn't it? I thought the rpm info was stored in Berkeley database, and has pointers to the real files on the disk.
Applying RPM in a more generic way to user data files would get you the same result if you tack on a search engine.Let's see, even without it:
rpm -qa|grep tax
But the thing that freaks me? Do I really want a MS database product to use my filesystem?
So does Anonymous Coward have good karma?
I'm not much of a hardware guy, but it seems like you could work this out if you had a small (50MB?) partition whose filesystem was something "known" and "simple" (FAT32? NTFS? FAT?) that lived on the boot disk. This partition could contain a boot image of a trimmed-down version of enough of the OS to just read that DB and mount/expose partitions where ever needed in order to go into "rescue" mode. I'm thinking of something like Linux's initrd preliminary root file system image for SCSI and such, with added stuff.
That would work well enough, especially if you had some bare-bones framebuffer GUI that let you view and fix partitions, use a USB mouse/keyboard, tools to move files in/out of ramdisks, etc. It could get the creature feep something fierce, but you could easily draw the line at like 100MB of compressed image data and still come away with enough tools to recover data. You could also stick all this on a bootable rescue CD (although I'd be pissed if I had to tote around a CD in order to recover from a crash).
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
They say, "Relational Database Kernel", I say "Deductive Databse Kernel" and trump them.
I think we'd be better off replacing the relational database with a file system.
Just a joke SQLiers, just a little joke. I know they are indispensible. Really. I believe you.
-pyrrho
I did use command line copy on both OS's. I've also tried tons of "accelerator" programs that claim to be faster at copying. I tried same partition, different partitions, changing cluster size to every possible setting it allows, etc. With Atto, the drive performs well once write size gets over 256K, but the OS's internal copy routines for both command line and drag/drop apparently want to write one 512 byte cluster at a time and confirm it went to disk before writing the next one, which is crippling the write performance because the writes won't cache or stripe.
Just "right click, turn on write cache etc" (from a previous post to this) DOESN'T WORK. If you'd care to READ what I originally posted I mention that it indicates write cache is enabled when IT ISN'T. It's pretty obvious whether it is or isn't based on the write performance. When read is 80-90MB/s and write is 1/10th of that, there's a problem. It's called the OS is forcing write-through, i.e. confirm all data to physical disk instead of just write back to the cache.
As for the controller, it's a 3Ware Escalade 7500-4, not one of those POS promise things. The drives are 4 Western Digital 1200JBs in RAID5. My previous Escalade 6400 and 4 75GXPs in RAID0 had the same problem. (this was asked in one of the previous posts)
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
"fsck" usually isn't a typo!
I think the performance of WinFS will tell us how serious Microsoft is about really changing the way files are used. Performance is just a question of time and engineering resources - OS X's journaling is slow but HFS+ is an antique filesystem; in contrast BeOS had BFS, a journaled filesystem with all of the indexing buzzwords WinFS claims except free-text context searches and it was also extremely fast.
The difference isn't features - BeFS supported everything HFS+ does and arbitrary attributes, journaling, much larger file/filesystem support, and indexing and it was still faster. Be simply made performance a much higher priority than Apple has so far; fortunately they've hired the BeFS lead developer and perhaps 10.3 will have some surprises.
Another good example is ReiserFS - while some of their choices reflect overall design goals (e.g. targeting large numbers of small files instead of BFS's massive videos) they've largely passed the traditional filesystems in most areas despite having to do more work to keep all of the extra features going.
Microsoft has a number of engineers who do understand performance; the question is simply whether it'll be a significant priority for them to make WinFS fast enough that we'll realistically be able to use it.
Personally, I still have reservations about using a relational database to keep track of files. Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be.
Microsoft already has a file system that is integrated within a relational database. If you install Exchange 2000, you will see an M: volume on your local drive. You can flip thru this using Explorer as if it were an actual drive. In fact, it is a representation of a back-end relational database. The speed seems adequate to me so long as you have less than 8 GB in your mailboxes and public folders.
jwg
You are so l33t!
What with your 'Corp' and all.
...the Zealots go "oh it's about quality, not innovation".
Yet when MS doesn't do something first, the Zealots go "That stupid Bill, he can never come up with anything on his own. He has to let others do it first."
Well, seeing how much of a pain in the ass I once found using an NTFS drive when trying to boot from disk - or share partition space - I'm not sure I'll like this one much either. FAT32 can be a pig at times, but with mostly-large files anyhow, and a big drive it doesn't affect me much.
Now, making a whole partition unavailable to my "legacy OS" is a real pain. Win98, which up to awhile ago was still the only thing that worked with my old apps... though XP is functional now with new drivers, but not perfect.
And, oops, virus, screwed up windows, whatever... boot disk no workie with NTFS, it's a pain. I think I'll stick with FAT32...
My old OS can still play with it, I know it doesn't have any unexpected glitches, and even 'nix can mount it nicely.
However, for the future, as in a few years, maybe I'll check it out - if I even run an MS operating system by then.
Oh, and speaking of 'nix, aren't there utils to link a database into the FS to optimize searches? It's not entirely necessary to do it all the time by integrating into the FS, just do a scan+update on a periodic basis
It might just be entirely possible that microsoft bought a licence from namesys for reiserfs. Reiserfs doesn't have to be GPL you know.
see: Business Model and Licensing for more info.
That's the goal. A local Google where you type some keywords and you get a big ass list of everything relevant.
If they can get it to work, it'll be a real productivity win.
The article is rather low tech and does not provide much information. It covers mostly old file systems and only little is said of WinFS.
Usability engineers looked at what users were doing in Windows and they saw that tons of people weren't using the filesystem - at least not directly. They were just putting everything on the desktop. If it was on the desktop, they could find it. They kept folder structures to a minimum and organized things visually (or not at all).
This posed a significant problem, so indexing and searching and abstracting the filesystem was one of the solutions. Instead of having to navigate a filesystem (hard for many users), you just type in what you're looking for and *poof* it appears. Not sure what you're looking for? Start describing it... *poof* it appears.
I'm not saying this is the right solution, but technology is not always about cluster size and performance - especially if the system isn't usable. It will be interesting to see how user friendly this WinFS thing is...
3 years before release: Product will do everything for everyone.
2 years before release: Product will do everything for the majority of users.
1 year before release: Product will do many things for many users.
Release: Well it does something.
"To those who are overly cautious, everything is impossible. "
The former British computer firm ICL (now, at best, a subsidiary of Fujitsu) invented a context sensitive file system called CAFS. This was hardware based and could search up to 1MB per second!
Looks like another piece of MS innovation.
Commercial licenses for ReiserFS are available; according to Hans Reiser, Namesys makes most of its money from NAS vendors who don't want to reveal that they use ReiserFS.
Sure there is. Except for the lack of standard interface libraries or any shell integration. Lunix is teh best!
I use journaling and still get filesystem corruption that is not automatically fixed (like overlapped extent allocation) once in a while. On the other hand, HFS+ seems to already use a B-tree and file search is quite fast.
Damn, so I have to buy Microsoft SQL Server and the Internet Connector License for something like $10.000 just to run Windows?
They're after my money again.
Microsoft loves to create incredibly complicated, undocumented and fragile data structures. Consider word: the internal structure of a word document as itself a filesystem, it has a root, a FAT and a bad block list. If even 1 block is damaged the file is useless. There are few repair tools because the internal layout is secret and undocumented. Access and SQL files are worse. In data recovery we frequently recover 90% of the files from volumes that have thousands of bad blocks or other damage. That wont work with WinFS. Are you going to store you precious digital photos on your $80 WesternDigital 80gb drive with its new 1 year warranty? Microsofts (and WD's) attitude will be that you should have backed it up. How do you easily back-up 80gb anyway?
I Agree With This Post (it's 4 GB)
The article doesn't cover WinFS. It has almost nothing to say about, it just surveys the existing MS file systems and is nothing like what the title suggests.
Don't read it, a waste of time if you know anything about file systems.
One thing I have never understood is why it takes so long to find files in FAT/NTFS systems even with their evil indexing services which grinds away at the disks and gobbles CPU cycles at random intervals while slocate is instantaneous and the update is almost as fast (slocate -u). I haven't tried slocate on windows partitions, but I expect it would do a similar job here. Perhaps someone could port this over to save us from needing longhorn?
FAT32 Formatting in Setup is an option, but is known to frequently fail or have significant errors
No it doesn't.
Just a side-note, when you format a drive as FAT32 using XP/2k, Win98 won't recognise it and won't let you install to it ("Bad Media Block"), eg. when you want a dual-boot between 98 & 2k.
Also, if you have a look at the Partitions while using a Linux-based partitioning app (eg. Disk-druid, fdisk) you'll see a whole stack of < 1MB or < 4MB partitions everywhere.
Yurk. fdisk all the way.
Both files and directories are merely inodes (loosely: pointers to the actual file data) and a directory's raison d'etre is pointing to a list of inodes and their associated "file-"names (including for itself).
That's why people sometimes say "a directory is a special file".
The upcoming WinFS file system will be the first to be context-dependent...
Clippy: "It looks like you're opening a Video File. Wouldn't you rather want to write a letter instead?"
Does this mean that finally the Windows file transfer counter will give sensible answers? Right now the only thing you can be sure of is that whatever it says, it's going to be something else.
Beep beep.
Actually, when you delete a file in linux (or any other *nix), you do not actually delete it yet when a process still has a handle to it; it only becomes unopenable for processes. Only when the last process that has a handle to it closes that handle, the disk-space containing the data for that file will be freed.
Compare this to DOS/Windows or NetWare; there a file cannot be deleted while a process has it opened. You will get some sort of error if you try.
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
This is about denying Linux and BSD compatibility to their file system. NTFS is being reverse engineered as we speak, write access is being worked on, so obviously Microsoft needs something new to get rid of them pesky Linux people.
All the new and great features could be done with a (simple?) layer between NTFS and the application. There is no reason why Microsoft needs to invent a new file system here.
Realistically there isn't any reason why a file system implemented as a transactional database couldn't be as fast as a traditional file system and a whole lot more stable. The only additional overhead that theoretically is built in is file creation/deletion/moving. Reads and writes to disk for most of the better implemented databases tend to be at the cutting edge of what most systems can even push to disk. If they limit the functionality to the few goodies listed in the article it will actually be a joke on MS. This thing has a LOT of potential, ESPECIALLY on low end hardware.
Perhaps for trivial stuff, but when a server starts getting stressed, ext2 bombs. I have been running an industrial strength SMS gateway system since 1999. We started off using Mandrake Linux, switched to Debian, and finally switched to FreeBSD (still using FreeBSD). The filesystem issues that Linux has are prohibitive when considering it for high-stress server usage. FreeBSD is far better in this regard.
Anyway, when i first heard about WinFS (maybe a few months ago), people were saying that all data on the hard drive would pretty much just be stored in a big blob, and that the database would basically index where each "file" in this blob is. Now, from this article (and from the comments i've gathered here) that doesn't seem to be completely accurate, but... eh. Database is a database i guess.
So i thought, if the database is doing the job of indexing these files for the operating system, then theoretically you could have, like, a database of what basically amounts to a whole bunch of symlinks. So you'll have your blob of file(s), your "original" database, and then your "symlink" database (for lack of better terms). I was thinking, if you could have that symlink database, you could pretty much choose where in the file system (as it appeared to you, the user) each file would go, and how it would be represented.
For example, say that you want My Computer to just be / (like on UNIX, basically). You could have a utility that tells your symlink database to set My Computer's "location" as /. That is, it "holds" all your drives and stuff. So then maybe you could set C:\ (your primary hard drive) to something like /hda, and set D:\ (your DVD drive) to something like /hdb. Et cetera.
Say you never messed with the stuff in your Windows directory, and you don't want a bunch of extra junk on the root level of your hard drive. Tell the symlink database to hide /hda/Windows (if we're continuing with the file system i'm kind of creating right now, heh), and that's that. It's basically like a hidden file, i guess, but that's not really the point (hiding folders, that is). The real point is, say that you did mess with your Windows directory, but you didn't want it on the root level of your hard drive, for whatever reason. You could tell your symlink database to "mount" the Windows directory to any place your heart desires. So, if i wanted, i could have my Windows directory located in /hda/hax0r stuff goes here/i like bacon/kthxbye.
Stuff like that. Or i could tell the symlink database to hide certain types of files. Or i could construct a full UNIX file system in Windows, complete with /dev, /usr, /bin, /etc, and all that other jazz. Or i could create my own file system (as i kind of did above with the /hda stuff). Maybe the symlink database utility would come with pre-set file systems for the user to choose from. Or something.
I don't know, i just thought that would be a neat idea. I know that symlinks and aliases and all that can kind of (but not completely, in most cases) accomplish the same thing, but a databased file system like what i described would be far more robust and manageable. Just a thought i had. :/
Am I the only one really annoyed at this guys use of "memory" for disk space? I _still_ find customers who can't tell the difference between RAM and HDD, and this guy goes and makes it worse for every twit who thinks they know everything. Yes, I know that one can make a theoretical argument for using the term, but really, in practice, memory is RAM. It's just annoying... I'm surprised to see it at Tom's Hardware...
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
Postgres as an rdbms backend to a filesystem front end.
3
Designed mainly for version control. Could easily be modified for other purposes though.
http://www.linuxjournal.com/article.php?sid=138
Government of the people, by corporate executives, for corporate profits.
That shows in a simnple fashion the difference between a db (used by locate, updated typically nightly) and a normal fs (probably an ext2).
Worth pointing out is also that the WinFS is AFAIK done somewhat similarily, i.e. the WinFS is run on top of NTFS.
Note that a "relational" or "set theoretic" filesystem does not neeed to mean SQL. SQL is the COBOL of relational systems.
:-( ), and the same file can be in multiple directories, just make the filesystem able to instrospect on a file to determine directory-membership,and perhaps add union, difference and intersection operators on directories (though they could be built in userspace, it'd be more efficient in-filesystem, and e.g. AmigaOS already had union operations.)
Personally, I'd like a set-theoretic FS. You could even do it reasonably easily with a small change to today's technology - just make the (unix-like) filesystem be able to answer, for a given inode, what directories that inode is linked in. Combined with hardlinks (including directory-hardlinks to allow membership of sets by sets to give relational capabilities... i don't buy the "circular reference" argument, one could GC the filesystem.), that instantly gives you a set-theoretic system, where each file can be truly present in a number of "sets" i.e. directories. Consider the statement: "Saying a file has attribute X is equivalent to saying it is a member of the set of all files with attribute X."
If directories are sets (and they are, except they mix in name-assignment too
With "stat -c%i" and "find -inode" in a shell script you can already emulate a lot of this, to a level sufficient to multidimensionally sort your... uh... image library. I might write a k5 story detailing the method, if I can be bothered.
"using a relational database to keep track of files"
I don't believe it, I've been hoping for this recently.
Could it be plausable with specialised hardware, such as the database itself stored seporately and keep tracked data seporate?
I'd really like to be able to search quicker, a linux database fs for just a few files on a seporate harddrive anyone? I can't run updatedb constantly, but if it was incremental that would be interesting.
A blog I run for the wealth
Personally, I still have reservations about using a relational database to keep track of files.
Isn't that what what the AS/400 does..?
(At least, I hava a faint recollection of my old man (mossy old main-frame-guy) arguing this as a reason why OS/400 is surperior to Unix.)
Ethics is what you say you do. Morals is what you actually do.
"WinFS is not a file system" Now they are using recursive acronyms as well. Someone posted this on /. before, had to repost this one!
This is gonna be a M$ classic :)
I think filesystems like WinFS are just an extension of applications like PCDOCs - as a result it is very useful for large organisations with large numbers of files and employees who need a database to find any of there files.
I also think that relational file systems might not be considered that useful for the home user - yet. But many of us are already having trouble organising all our files, so I'm sure it will take off for home use to.
As for a linux version, anyone interested in creating something I'll call "relfs"?? What I think would be cool would be couple a relational file system with a version management tool - you can find any file and any previous versions of it.
Take a look at www.namesys.com/v4/reiser4_the_atomic_fs.html
and at www.namesys.com/v4/v4.html.
We will be adding support for semi-structured data querying in the next major release, assuming that we find funding for it. The semantics for it are described at www.namesys.com/whitepaper.html, which also explains why I don't think the relational model is effective for semi-structured data stores such as a general purpose filesystem is normally used for.
Best,
Hans
> Geeks everywhere have been doing this already
> for a long time. It's nothing new or innovative.
Only, coming out with a crap-ass alpha isn't the only thing that counts as "innovation". Pushing it out into the "real world" and getting real people to use it also counts.
To that extent, Be is the only one who has innovated here - because they got a decent FS out into the hands of actual users (that they didn't get too many users is not totally thair fault). As for random geeks developing "their own libraries", and Gnome's VFS -- I suggest they ship something real before you start drooling about 'innovation'.
Go somewhere random
[i]fragments all to heck and back.[/i]
Does it really affect performance? I am not sure about that. But the reason that you see the fragments is because the defragmenting utilities show them. They create the need for defragmenting by showing the fragmentation.
The difference between differnt file systems is still often a factor 6. This is in the design, and has notthing to do with fragmentation. Any file sytem will have severe fragmentation if the disk is used with very little space free. This is exactly what happen with the average geek PC that will get overloaded with gadgets.
By the way, i have seen a ext2 defragger. quality was "use at your own risk".
Because of the 'Linux' in 'Linux filesystems.'
So I still need a dodgy defrag to keep my disk nicely packed or it finally does like ext2, where you keep it clean just by using it?
I guess this is still on topic but...
...........
I noticed NTFS wastes a lot of space with its MFT. Creating a batch file to test NTFS shows how space is not recovered when creating and deleting even a small number of files. I figured it out after I noticed 600MB of file space missing on an empty drive that I moved all files from. After reformatting and copying them all back, only 90MB was used by the MFT.
[begin]
echo "----------------- 1:" >>AAAA
dir AAAA >>AAAA
copy AAAA BBBB1
copy AAAA BBBB2
copy AAAA BBBB3
copy AAAA BBBB4
copy AAAA BBBB5
copy AAAA BBBB497
copy AAAA BBBB498
copy AAAA BBBB499
copy AAAA BBBB500
echo "----------------- 2:" >>AAAA
dir AAAA >>AAAA
del BBBB*
echo "----------------- 3:" >>AAAA
dir AAAA >>AAAA
notepad AAAA
[end]
Running this in a directory more than once will show space is not lost but the first time I lose between 30K and 400K.
Can anyone using WinFS and NTFS see a difference?
Do your best, hope for the best, suspect the worst.
..This means I can't use Norton Disk doctor from '95 to "recover" my files anymore!????
Damn.
On a serious note, I'd love to see the development being done on forensic analysis of this new filesystem
Rob
Yes, I noticed since I upgraded from WinNT to WinXP, the file system seems to be much slower. When you open a folder in Windows Explorer it takes a second or two while in WinNT it was instantaneous. I tried tweeking it (removing indexing service, etc.) to no avail. The fact that I have SCSI drives makes me think that this might be what's causing it
The article doesn't address the most important question on every /.'ers mind:
Will copying a 200 MB file be faster or slower than on an old Mac 8600/300?
(For those who don't read Apple related articles often, this is a reference to a famous troll, not an attempt to start a "which OS is better" war.)
http://saveie6.com/
pictures could be about 40kb on average each, and it's easy to get 1000's of those.
500MB+ is great for DivX movies, which also come in the pr0n variety.
Learn from the mistakes of others. There isn't enough time to make them all yourself.
Avoiding deadlock, dealing with transaction timeouts, controlling permissions on who can keep a transaction open for how long, these are all very serious issues that have us first making transactions available to plugins and trusted processes only in the first release. However, there is a LOT you can do with just plugins and trusted processes to make user data more secure.
Why do people insist on using the term virii? The last time I checked, the only plural to virus is viruses. I wonder how he would spell the plural of jesus or venus?
SELECT * FROM [TomsHardware] WHERE NOT IsNull([Content])
---
(0 row(s) affected)
(Score:5, Troll)
Can I be your new friend? You realized what I always wanted to realize !
I thought the AS/400 did that. :p
Putting transactions into a file system is retarded.
An ACID file system would mean that images would probably take 10 days to write, and that, if someone was writing a long file, and a short file, all users of the short file would have to wait until the long file write was complete.
This is my sig.
Gosh, I did not know that. Amazing. Always wondered what that command stood for. :^P
One line blog. I hear that they're called Twitters now.
I noticed right clicking in Win Explorer in Win2K allowed you to apply attributes to files. Not sure if they were limited to MS Office files.(Sorry, I can't check this anymore ;-)
.AppleDouble directories for an approach to foreign datastreams...they can get ugly pretty quick.
I believe that NTFS supports multiple streams of data per filename much like HFS. However, Windows doesn't make the pervasive use of the capability that Apple did in OS 9. I think one reason is that pretty much anything can go in these multiple streams meaning that particular files are tied even more closely to particular applications. Another reason may be that multiple filestreams complicate transfering files from machine to machine.
You're correct about RPM. It is using a more conventional approach by chucking it's data in a database file. Read about Netatalk's
I know there is at least one gaping security hole in NTFS. By now, however, it is probably a class of vulnerabilities .
I noticed that its faster to copy a large file on a NTFS 5 (W2k and higher) partition to another NTFS 5 from BeOS 5 then in / from Windows Explorer.
:(. So I'm using BeOS to move files from there to a FAT32 partition that W2k3 can read.
For you who don't know BeOS 5 does support NTFS read / write of NTFS. I think they licesenced it or something as it works great except it leaves a folder called "RECYCLER" and it shows all the hidden system filesystem structure files / directories.
I'm now using the BETA of W2k3 Sever and it can't read my old Win2k NTFS partition. It says unknown filesystem and I can't mount it from the logical disk manager
-- I don't buy it, I grow it.
Soon, your OS will be based on a RDB, so get over it.
I am very small, utmostly microscopic.
Heyyy, that's our clever geek naming convention... (WINFS = Winfs Is Not a File System)
My beliefs do not require that you agree with them.
Smells like AS/400+DB2!
Hey! As long as you're going to combine the FS with a DB, why settle with the relational model? PICK all the way!
What FS do you think Dell is going to use?
My point is, in percentages there is no choice. When you say "you" have a choice, you are referring to the very small percentage of people who know what a file system is. Ask 100 people what file system they use on their computers, and most will probably say "windows".
That is how Microsoft works, they play the percentages (which they own). So yes, you do have a choice, but the collective "you" doesn't have a choice because they don't know or care what a filesystem is. I know, this is Slashdot, and you have to speak to the crowd, but to win the "game", MS doesn't have to win over this crowd.
And for all I know, WinFS may be awesome - but I'll probably never use it.
My beliefs do not require that you agree with them.
When you end up with 200 Megs taking up 1Gb on disk I'd say it affects performance.
That is called slack. And that is a problem with many small files. Especially under FAT the minimun amount of space a files takes is quite large. That NOT fragmentation.
Defragmentation almost never saves you any space. saving space is called compression. (And compression leads to fragmentation in w2k, now that is a braindead implementation!)
Fragmentation (might) occurs if the is a low % of free space. 1 GB free on my 120 GB disk is bad. 1 GB free on my 4 GB disk is (mostly) OK.
One quiblle:
And for you hard-core naysayers out there, you have to ask yourself this: If this is such a bad idea, then why did Oracle provide this as a feature too?
Because Oracle is as monopolistic in intent as MS, just not quite as good at it?
IFS was a horrible failure. Oracle has a history of this sort of thing - throwing something out there and hoping it sticks, without really treating it like a true product. Remember WebDB, I think it was called?
IFS has a lot of problems (interaction with backup tools, orthogonality of intent, decent tools to take advantage of what gains actually are there, etc.).
Even the link you posted reads really defensively, as if a project manager is attempting to justify their job.
I forget what 8 was for.
Tom says that NTFS stores file system information
in the registry. All of a sudden I am worried that
if my primary drive fails, I won't be able to read
the files on the secondary drive, even if I mount
it in a working system, because the registry information wouldn't be right for the drive. That would be just like MS wouldn't it. Don't a lot of people use a second drive as a backup?
What ever happened to PostgresFS. I seem to remember sonething about it in like 1997.
I never fail to be baffled at the degree of inertia in the IT world. I sometimes thing every computer person thinks technology should be frozen at whatever point they got tired of learning new stuff. "File name extensions and symbolic links were good enough for me lad!" It's a weird attitude.
:(
If I had modpoints I'd mod that up!
creation science book
Last I had read, WinFS is not a filesystem at all. It is a process that is run on the computer to index the already old NTFS. FS in WinFS doesn't even claim to stand for File System.
SGI's attitude that XFS is unbreakable, therefore they don't need to make tools to fix it is a pain in the arse. XFS does go wrong, it does stuff itself up, and can't always recover at mount.
They tried the "it can't possibly go wrong" stunt with Irix. A few versions later the repair tools turned up... Until they include some decent repair tools with the Linux utilities, I have no intention of letting it anywhere near my data, I've been burned by that one before.
Least thats all ive read so far.. the drive will still run NTFS but there will be an additional database that allows for relational searches.. a bit like Indexing service now.. jsut that it will waste even more space and resources as well as allow MS to take full control of all your files.. incorporate heavyass DRM and other shit!
"All users of the short file would have to wait until the long file write was complete"
You do realize that change-vectors in a journal can be interleaved?
And that there are well-known technological solutions to allow concurrent r/w operations in a single file/table without readers ever blocking writers? (i.e. Oracle or PostgreSQL's multi-versioning)
The only part of an ACID file system that usually requires some leeway, as in a database system, is the "I", isolation. You could crank that up or down depending on the needed semantics of your situation. Consistency and durability are there in most file systems, atomicity less so.
-Stu
>What I think would be cool would be couple a relational
>file system with a version management tool - you can
>find any file and any previous versions of it.
Didn't VMS do that back in the 80s?
"America has done some terrible things. But I know that Americans don't cheer when innocents die." -Dave Barry
Sourceforge will soon have another project called LinFS that is compatible with WinFS.
From excellent karma to terible karma with a single +5 funny post...
I'd live to finally see the ability for an MS filesystem to allow for true symbolic links.
Trolls lurk everywhere. Mod them down.
Why do people do things simply because they can?
-Slashdot Junky
.
Landfill Mining Co.
Managing the (Un)natural Resources of Tomorrow
BeOS? There file system was based on relational databasing as well, or did people just forget that? Who wants to bet that Microshaft just ripped that off of the now-open-source version of BeOs... Just a thought.
WinFS Is Not (a) File System!
See the subject, biatch.
"America has done some terrible things. But I know that Americans don't cheer when innocents die." -Dave Barry
Personally, I still have reservations about using a relational database to keep track of files.
A hugely conservative Slashdot reader? No way!
Not having read Tom's Hardware review of WinFS, but from the sound of things of the post, if WinFS is supposedly using a relational database to keep track of files, this sort of already sounds like what MS is implementing in some of their exisiting software such as Exchange and Sharepoint. Sharepoint utilizes Exchange-like file system where you can store files into the Sharepoint repository. In the first delivery of Sharepoint, there was an upper bound on the size of an individual file to be stored (I believe it was an 4GB limit) but in the current release I believe there is no upper limit. From what someone had told me if i recall right, Sharepoint utilizes the SQL engine to keep track of the files that are stored in Sharepoint. Maybe MS is just taking what they have learned from Sharepoint and making it more 'general purpose' for day to day use.
I've seen the same sort of progressive slowdown with my Win2K box using NTFS that I used to have with Win98/FAT32, and that's only using about 2/3 of the drive or so. I've never seen a filesystem on Windows that didn't regularly get horribly fragmented and accumulate a noticeable drag on performance (with a resulting return to "health" after defragging).
"I call a baby goat a 'goatse.'" -- my non-Internet-savvy 6-year-old stepdaughter
HOST $dir login.com
Directory DEV:[DIRECTORY]
LOGIN.COM;10 LOGIN.COM;9 LOGIN.COM;8
Total of 3 files.
Let's get one thing straight ... many of these features are already available in one form or another and no one uses them.
... I'm not against having an FS that enables you to annotate files outside of the programs that create them. I remember working many years ago with FSs that would allow you to automatically keep the last n revisions, which was very helpful when coding.
How many people click on Properites in M$Word and put in the information?? How many people download files and leave them lying in whatever directory they just happen to fall in.
Don't take me wrong
It's just that I have a hard time getting excited over something that is going to simply bloat a system and the odds are no one will use.
My girlfriend is fairly smart, but she still downloads all her pictures into the default folder, and uses thumbnails to find the ones she wants. She has about 1000 of them, and it only takes here a few minutes to find the ones she wants. It would take here no extra work than what this new FS is suggesting to rename the file and/or store it in another folder
Useful feature, bloatware, Linux beater, or disaster waiting to happen. My guess is all of the above, at one time or another. Some people will use it and spend hours cross-linking files. I'm sure the initial releases will have security or data loss issues until the bugs get worked out. It will take 0.10 minutes for some Linux hacker to reverse engineer the ability to at least read it. And it will probably take up gobs more memory.
It's all a matter of perspective....
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
When designing your revolutionary OS, as Microsoft claims they are doing - why wouldn't you want to include a new way of implementing your DRM.
Namely a relational database under the guise of a filesystem.
That's about as core a component as you get.
Heil Gatezen!
I love the name after hearing Win FS I was thinking Windows file system. As the years go by softwate gets funkier and funkier names.
A filesystem like this is great for organizing music and media files, something I know a lot of people currently struggle with. Songs frequently fall under multiple categories at the same time solving the problem of not being able to sort music by author and album at the same time with directories.
Chris
Microsoft can require the bootstrap call routines from a separate DMCA/Patent protected, Microsoft branded, bootstrap ROM, and can control motherboard vendors through licensing for that chip.
Nasty Microsoft if they try that. Someone better get some prior-art out there and QUICK!
--- Nothing clever here: move along now...
If I recall correctly the first file system to incorporate both a relational database and journaling was none other than BeOS's file system. It was pretty ingenious back in the 90's.
As usual M$ embraces and extends....
This idea isn't new... Microsoft as long been trying to nip at the heels of IBM's midrange platforms. The system/38 shipped with a relational-only filesystem over 20 years ago. This filesystem is still alive in the AS/400 and iSeries systems. The advantages really are nice... merging the filesystem and the database, combined with a really smart optimizer, allow you to run a high performance database without having a DBA constantly monitor it. You end up with no tablespaces or any of the rest of the cruft that occurs when you try to build a database using files.
If it were just that, it might be laudable... but what MS is trying to do here is really more nefarious... MS is really trying to rid itself of all non-MS databases on Windows. This is the old IE vs Netscape trick. Why would you buy a real database when you're forced to buy SQL server anyway? Enough people might not know the difference
Let's assume they will use (modified)SQL Server for the relational database, so it'll be installed on every Longhorn computer by default, and, knowing MS, it'll be setup insecurely(think of across-network searches of remote volumes).
So, a worm that works like SQL Slammer will spread even faster.
YAY!
I wouldn't be surprised at all if this is what motivated MS engineers to do this, but it also highlights one of the problems MS has: Their broad user base. As someone who just lost his job admining 20 Windows users I know that just as many Windows users never use the desktop as MS might assume. While Windows offers just about as much functionality in terms of drag and drop and meta key modifiers (Ctrl-Drag for copy etc) as the Macintosh does, Micorsoft never advertises this functionality. Most standard users don't even know what the right mouse button is for and do most actions either through the toolbar or the menu.
Oracle has a database hosted file system as well, the Oracle Internet File System.
e s/ index.html?ifs.html
http://www.oracle.com/ip/deploy/database/featur
I suppose if I had to have my filesystem in a database, I'd rather have it in an Oracle database. Lord knows how much fun M$ SQL Server has been.
To sum it up : WinFS will be based on a relational database of some sort. That is ALL this article says about WinFS.
It goes on to tell you about FAT16, FAT32, and NTFS 4.0 and 5.0 (which they don't even bother to number).
Good info on the previous FSes, but comes up short on the topic that the article was meant to encompass, namely the WinFS filesystem. If you're looking for hard-core information on how it works, you're out of luck.
I don't know why anyone should care about it. The only place I've ever had trouble finding anything was on a Microsoft platform. Everywhere else find and grep come to the rescue and don't take much time at all. You would think that someone would slap a graphical front end on a combined tool.
Friends don't help friends install M$ junk.
One of those is more than 20 MB in size...Currently, however, all existing system files have no function or produce nothing more than error messages.
that's the default behaviour!
I found that a tad amusing.
maybe $ms-gorillaz invaded/cracked their servers and uploaded it. Xor payed them (the greedy-capitalist of THG) to put it there them selfs (if you look, at THG now, and a few years back, one can conclude that greedy-capitalist have increased in THG over the time).
I don't claim I know more than I know, and if you know you know more than I know, then by all means, let me know.
Finally, I can stop naming my folders like: ...
;)
cute brunette
cute brunette in dress
hot blonde with guy 1
hot blonde with guy 2
hot blonde with dildo 1
Now I can attach meta data like
hair color,
props (clothing, toys, surroundings),
# partners,
partner gender(s),
whatever else... you get the idea
no comment
For most file data, perhaps.
I will use this, and to good effect, as well.
The point to take into consideration is that the context will also change depending on the metadata available. Your view of the aggregate file objects changes, depending on the context. Not to mention that this same metadata will be available, in the same format, to all participating applications. Your apps can have all the same view, if you like.
What this means in concrete terms is that your carefully sorted directory of MP3's can look like a file library in iTunes. There are searchable, sortable columns for Title, Album, bitrate, Cover Art, year, label, and whatever (note I did not say "filename", which is just another attribute under a modern filesystem). This is possible with only the most basic gestures on the part of the user, and is remembered for the next time you visit this same view.
Similarly, a tree of photographs appear in any participating file browser with whatever columns you want (bit depth, format, date taken, date published, ICC info). It's important to consider that you can do this with any arbitrary collection of data, even one's you define yourself (to take the BeFS example, anyway).
So you can take your collection of widgets, define attributes about these widgets, and your file browser applet works the same for the same user in all applications. It should, anyway. This is why we have APIs.
To cite your example, why visual grep through a bunch of thumbnails looking for a particular photo when you can just indicate with a few gestures the "type" of photo you are looking for? I like the iPhoto interface when I'm browsing photographs, but if I want a particular photo of the GF from a rough date taken at night, I certainly don't want to browse through 1000's of images, especially when some of them can be hard to discern at thumbnail resolutions. I certainly don't want to do this repeatedly when I'm assembling a photo album on a specific subject.
Let the computer do the grunt work of selecting a result set that matches my criteria, and then I can use my human abilities to select the object I want, or refine the search.
Most of us already keep our aggregate file types in associated groups on the filesystem already. In most cases, the tree structure of most filesystems is sufficient. All this does is extended the functionality of the filesystem so that you can choose to abstract aggregate file objects and treat them in a a myriad of different ways. In the most basic sense, you tell the OS, "look, when I have the Explorer/Finder open on this directory of MP3's, make sure you change the column view so it shows this, this and that. In icon view, make sure that mouse-over pop-ups (if enabled) display this that and that. Default sort is alphabetically by Artist's Last Name. I don't want to see the filename, as that doesn't contain any useful information."
That is, you don't have do anything special to make use of the file attributes in this way. You just tell the ultimate app that all of us use the most (the operating system's file browser) to treat certain directories in a different manner.
-- clvrmnky
Does anyone know where we can get the Longhorn Alpha release?
Well, VMS has database support in the OS, and file versioning, but RMS is not actually integrated within the file system.
Gamingmuseum.com: Give your 3D accelerator a rest.
Is this a need based OS mod or is Redmond just scared of Linux NTFS? You can mount for read and write is soon to follow.
It is my understanding that fat32 limits the number of entries in the root directory to 65,535. Can someone shed light on this?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This will eventually close the markets to products like Oracle's Collaboration Suite. The main advantage to keeping files in a Relational DB layer is that changes can be related to transactions and can be rolled back without having to resort to a restore from tape. This is handy if you're developing code or keeping track of a huge number of user files and restore requests. When this functionality is built into the OS, it will put the nail in the coffin of anybody offering Content Management Systems.
So all Windows PCs in the future will have files sytems based on a relational database (i.e. SQL server).
Imagine how much more devastating SLAMMER would have been if it could have infected every one of them instead of just the ones with SQL server installed.
I don't think the inefficient overhead will be a problem. The new Intel IC's and frontside bus speeds need somthing to do.
What I wonder is, how will the Linux community respond to this.. will Wintel machines take over?
Ross Youngblood
All it did was put 'WinFS' in the title, then proceed to talk about the advantages and disadvantages of the other, existing file system.
It had no new information on WinFS whatsoever.
Useless.
.... partly..... and barfed.
I know a thing or two about filesystems: I work in the data-recovery business.
This article was written by someone who has some basic details, and has fantasized a lot of incorrect info around it. Bunches of terms are used incorrectly etc. etc.
NTFS is a very well-thought-out filesystem. It can be made to perform well, and has almost no limits. (it does have limits: For example, files are limited to about 16 Billion gigabytes. Something like that....)
I sure hope they don't throw away the good things about NTFS....
Microsoft makes very little "good" software. But the NTFS filesystem generates the impression that it's different. They probably didn't design it themselves.
Actually, when you delete a file in linux (or any other *nix), you do not actually delete it yet when a process still has a handle to it; it only becomes unopenable for processes. Only when the last process that has a handle to it closes that handle, the disk-space containing the data for that file will be freed.
I always figured it was because when you "delete" a file, it just makes the inode stop pointing at the data, it doesn't actually destroy the data. That way, if a program already had the file open, it would "know" where on the disk the data is, and it would still be able to access it, even though the inode it used to open the file has been freed.
and my roomate can never remember where he saves his documents. A feature that enabled him to search by author or by title in *reasonable* time would seriously help people who find sprawling directory trees intimidating.
---------
Get back to me when my brain starts working.
Unfortunately, HFS, FAT(16/32), BFS, NTFS... none of them have this built in.
I want to see a filesystem with Evil Bit support!
Did you even read my posting?? I didn't say it wasn't a good idea, I just said MOST people wouldn't use it, and I wasn't getting very excited over it. I would probably use it, you would probably use it, and other anal geeks like us who spend hours getting the most out of our systems will probably use it. But Joe Average down the street, the same guy who doesn't know where his downloads end up, won't use it. So, in my humble opinion, it is bloat.
/. effect.
And, to use your example, what if the file system used it's existing file type/program associations, and if you wanted a detailed view, the associated program would sneak into the file and display the information for you? Isn't that what happens now with Word and Excel? What this file system is doing is duplicating the information already in the file and storing it in the file system.
It would be very easy to add an option in the file association tab in Windows so that an executable can be run to extract the summary information from the file. No change to the existing file system format would even need to be done.
Two ways to get at the same data. One pays a penalty for when you want the data (extra I/O to open the file and look at it), the other pays a penalty for every file stored (redundant data storage.) These are common compromises made in every database by the designers, and there is no one correct answer.
My preference would be for the former. It is far more flexible and mirrors my view that the OS (including the file system) should manage resources and not data. If I want and/or need an advanced file browser or file system, let me buy one, but put the hooks into the OS to support alternatives.
<rant>But, that is not the way of the M$. They are far better at creating proprietary methods that lock you into the 'one true way' that the megalomaniac Bill Gates sees the future as. </rant>
Sorry about that rant,
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
There is a huge misunderstanding: SQL is corrupted, not derived, from the relational model. Since SQL deviated from it, the relational model has been developed significantly by Hugh Darwen and Chris J Date among and above others.
So MS is not proposing a relational data storage instead of a file system, but a SQL data storage. Or perhaps not even SQL, as MS SQL Server is notoriously almost as little SQL-compliant as Oracle itself, the king of standards deviations, second only to MySQL.
BTW, if anyone tries to tell you SQL is really relational, or quasi-relational, don't belive the Marketspeak. You can't be quasi-Mathematical, and the relational model is really an implementation of set theory and predicate logic. Tables aren't relations, just like 2+2=5 is not Algebra.
Pragmatically, this prevents SQL from being as flexible, simple and performant as a relational system is. There are some examples, unfortunately mostly historical: Ingres QUEL was found to perform consistently better than SQL systems, and much better than pre-SQL systems that had SQL grafted upon; BS12 was much cleaner, as was QUEL, than SQL; nowadays Alphora Dataphor is extensible in a much cleaner way than current OO or SQL OO systems.
In its defense, it may be that Microsoft uses only the data storage engine of MS SQL Server in WinFS, just as it uses it now for Exchange. Getting rid of SQL looses many interesting, powerful capabilities, but also may unleash performance. It even could be perfected as the engine of a future, nice, relational system, if ever Microsoft wakens up to what Alphora and TransRelational are (trying to) do. But I very much doubt; most of the database field, both academic and corporate, is corrupted by SQL money; there simply isn't enough cultural critical mass for a big company as Microsoft to steer its course from SQL to relational.
Even so, this could be the single most important contribution of Microsoft to the Informatics field, on a par with making the x86 computer a commodity. Even a sub-relational system can be so much better than what is around; this, together with Moore's Law making inherent Wintel inefficiencies irrelevant 80% of the cases, could pose a very big threat to the competitive position of free software. Granted the GNU/Hurd, or perhaps even Eros, could implement something even better than WinFS, truly relational and with orthogonal persistence in the physical layer (Eros) and/or a functional language application layer (GNU/Hurd). But there is no talk of doing so yet, and it would take a long time to bring these systems to where GNU/Linux is now.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I, in fact, did read your posting. I disagreed with your contention that most people would not use it.
My examples were actually counter to any filetype association cruft that some operating systems default to. This is not what these types of file systems are about. Why limit yourself to three letters and a global registry entry that gives you one of a few static views?
*shrug* My only experience with RDBM-style filesystems is the BeFS. Folks who used BeOS didn't have to be technical wizards (most didn't even bother installing a POSIX shell). Everyone I know used the BeFS in this way, however, for aggregate data where it was useful. For example, most people just manipulated their MP3 files based on the information in the ID3 tags. They rarely viewed the filename ever again; with a few mouse clicks they made the Explorer view of their MP3 directories report bitrate, album name, etc. You could edit your ID3 tags through this views, as well. You could select a number of MP3's based on any number of keys and edit all the ID3 tags from the this same view. No third-party tool necessary. It just made sense, and was dead simple to do.
Once you opened a view on some other "directory", your view changes to the default one, or another view based on other, possible unique, meta-data.
Once you learn how do do this, it becomes a natural way to view the "filesystem".
Sure, only the power users defined their own meta-data to incorporate into specific views. Getting started was dead simply, however. The apps you used then could concentrate on doing what they did best, and cooperated with the OS to provide filesystem views.
I think it's important to note that this file system has a specific use: it's really geared toward user-interaction. This implies two things:
This means that this is not the perfect filesystem for all reasons and all seasons. If all you need is a basic tree-structure, and have no need to hide or filter the generic view that Explorer gives you, then fine. If you are looking for a fileystem that can stream data at a tremendous rate, then another one may be more appropriate. Even a tree-structure may not be good anough, and you have to build an Oracle-like extents system on top of the raw device.
But if you are making a file system that returns searches in a timely manner, "feels" responsive through the clever use of threading, and allows for simple gestures that instantly change the way you present and manipulate file data, then something other than NTFS or ext2fs may be appropriate.
My only point was that Windows Explorer is arguably the most used application in the world. Making this application behave more appropriately based on existing or user-defined true file-type-specific meta-data is good. Being able to instantly contruct unique views based on these meta-data is a good. Certainly accepting near-human search strings based on keys that may be unique to us, and returning those results in a timely manner can only be a good thing.
Monolithic, system-wide and fixed "file attributes" just don't measure up. As long as Microsoft makes it as easy, or easier, to use as the BeFS, people will use it.
Ultimately, all I can say is "have you lived with such a filesystem before?" This is one of those things that you can just make more and more use of, as you gain experience. But you certainly don't need to be a power user to reasonably sort and search your MP3's or photos.
-- clvrmnky
"My God, this must be a truly remarkable corn chip, to be so widely and confidently touted."
Does this mean that I can now store keywords and descriptions with image/audio data and have it go with the file when it's copied?
I read something in the article about metadata, but it seemed to be more along the lines of remembering the read only status of the file.
Read this, it might help.
http://support.microsoft.com?kbid=265396
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I really wonder about Microsoft's motivation for this. Are they trying to make Windows "the media OS" that BeOS promised to be? I somehow think it's more than that.
The article is rather thin on details, which has been noted elsewhere. One line at the very end of the article stands out:
What this tells me is that Microsoft is looking for a way to promote lock-in on the desktop, by making multi-boot systems difficult or impossible, and by making cross-OS reading of file systems difficult or impossible. But I think there's even more to the story than that.
Orrin Hatch recently proposed that some kind of measure be placed on computers (he doesn't specify how to accomplish this, just the behavior he'd like to see) to warn the user if they download illegal music the first or second time; the third time that the user downloads an illegal music file, the software that oversees this would essentially trash the user's computer. Now, anyone with two brain cells to rub together can see that this presupposes the ability to distinguish between a legally downloaded MP3 and an illegally downloaded MP3 -- virtually impossible, since MP3 has no built-in DRM. Many bands put MP3 files on their web sites. (Even major acts like the Offspring have made songs available in MP3 format prior to releasing albums.) The only practical way to implement Hatch's proposal is to essentially assume that all MP3 files are illicit, or to assume that all MP3 files downloaded from the network are illicit. This would essentially mandate a closed file format for music, forcing DRM down people's throats and effectively ridding the world of MP3, Ogg Vorbis, and so forth.
How is this relevant? Because if you put a stranglehold on the file system for an OS, you suddenly have the ability to police what goes into that file system, and where it comes from. And maybe, just maybe, this push by Microsoft to add more database-like functionality to their file system is a way to make it easier for a "watchdog" application to perform its cop duties.
The sad part is, if any other developer were to create a file system like this for any other OS, I wouldn't even blink. But because Microsoft comes up with this idea, I automatically start spinning conspiracy theories about their motives, and how they could pervert what could be a great idea and use it against the end users.
Signatures are supposed to be funny?
WinFS is not a file system. It will not replace NTFS.
Longhorn will require the use of NTFS for the system partition. It will *not* let you format the install partition as FAT32, as XP does. It remains to be seen if you will be able to upgrade to Longhorn on a FAT32 partition.
WinFS is a replacement for the Indexing Service in 2000/XP. It will become a lower-level process and, in theory, will be much faster.
It will also be a major part of Longhorn's new UI, which will let you easily and quickly view your data in ways other than simple file and directory lists.
Going to My Music Library in Longhorn will display all music files on your computer, no matter where they're located. They will be organized in a method of your choosing: probably defaulting to Artist/Album view.
Searching will be much faster. And if, for instace, I'm looking for an old paper on Othello from a Shakespeare course I took, but don't remember what it was called, I could search for "Iago perfect nemesis" and find the paper titled "Iago, Othello's perfect nemesis?" (with a file named shakespeare10-24-02.doc, or whatever), because the Search feature of Explorer will search the contents of files that match what I'm looking for. And since searching is done using a Yukon-based database, it should be fast.
The goal is to change the way "average" users access their data. It is the file-manager, the UI, and the Search functions that are being changed in WinFS. Not the underlying filesystem.
Another goal of WinFS is to remove the overhead caused by the Indexing Service in XP or 2000 (which is equilivant to running updatedb in the background all the time).
I wish Tom would get a clue. And I wish slashdot wouldn't link there ever again.
she still downloads all her pictures into the default folder, and uses thumbnails to find the ones she wants
:)
"Almost half of all people are below average."
Sounds like you need to teach her the fine art of pr0n management.
Nearly half of all people are below average
screwed up the formatting. The last quote is the sig, not to imply that your girlfriend is in anyway below average.
Nearly half of all people are below average
gosh, I thought they knew more about file systems. Quite a few basic mistakes about current files systems.
it's called trolling turdburgler
If microsoft has some serious white papers on the subject, that might be worth reading. For a big database, turning the kernel into your database manager (and getting rid of the file system middle-man) arguably makes sense. One thing that struck me about this article is that it didn't really spend much time talking about WinFS at all. The last paragraph just mentioned in passing that Microsoft doesn't even have a working implementation yet, just a broken executable file. The author also makes a lot of hay about all these old p.o.s. legacy file systems and how they're a mucho grande problem for those legacy MS OS's *BUT ALSO* Linux (laughable, I've never had trouble mounting a FAT based file system on Linux or BSD). Imagine all those billions of productive I.T. people out there with multiple OS's on their computer because they can't set up NFS or Windows networking! One thing that the article does demonstrate is Microsoft's habit for designing software that complex, bloated, and full of redundant features so that it sounds sophisticated and robust on paper but performs like a ticking time bomb at worst or a "work in progess" at best. Maybe Microsoft has had problems with big jumps in harddrive technology and backwards compatibility in the past; however, if they can't settle on one or two file systems by now, and refrain from making revisions to them every time a new version of Windows comes out, what are they good for? As for Tom's Hardware, his readers will probably rush out and format all their mp3-laden harddrives with WinFS the minute Longhorn hits the shelves, but no one who is sane will.
This is interesting, in fact. With a proper and efficient DB as a backend rather than a traditional FS, you could not only make fast searches, you could reorganize the way your data is presented to you.
/2003/June/1[5-8]/*
Now you are entering data in directories and files, but what if you want to find out what you worked on a particular series of days? You could reorganize your data on the fly so that your directory structure would now be presented in a timeline fashion. E.g. you would be looking in for files in
A nice database combined with version control could potentially find for you the changes to a particular file you made that day. All pretty much instantly.
You could decide to organize all the data any which way that would make sense to you at the time. You would not be stuck with a fixed directory structure anymore.
If this is what MS has in mind this could be a real advance.
Who says that efficiency is the goal of Microsoft?
After all, we KNOW the only reason for the new
system is to make it easier for the computers to
be romotely searched by data miners from government and industry. Your convenience or
profitability be damned! Microsoft does not
care, they don't have to care! They own the
government and the judiciary. Look at recent
court decisions. They are a cartel openly operating in the face of the Sherman Act and
nothing is happening to them. Nothing will happen
as long as republicans run the government. Maybe
not even then. Uncle Bill and his backdoor operator on the SCO board, Paul Allen, will see
to that.
First off, I know a lot more about databases than you might think. First I did a stint in a class action lawfirm. Our document management databases would index every document produced in discovery. This would be millions upon millions of rows, for a single litigation, and we would have dozens of those going on. After that, I decided to get into the simpler business of real time energy capture. That's just a few hundred million rows a year...
Transactions are not a panacea and their automatic use needs to be considered and considered carefully and for every application. A sweeping rule of transactions everywhere is madness.
Why?
There are two popular ways of dealing with transactions, multiversion concurrency control, as used by PostGres and Oracle, or, the locking protocols used by Sybase and SQL Server. With MVCC, readers do not block writers, and writers do not block readers, but, sometimes, a rollback in one transaction MUST force a cascading rollback in downstream transactions. The database stalls as do all of your users. On the other side, SQL Server locking, you avoid the potential rollback, but then, writers block readers. So, the database stalls, and users are still screwed! In both cases, in fact, in any concurrency scenario involving transactions, the system is going to tend to wait for the longest running transaction, when their is contention.
Of course I assume a serializable isolation level. If you are going to have that, then, what's the point of having ACID? You can't have ACID without that I for Isolated!
So, where could there be contention? Let's see, in Windows, we have the Registry and its relational replacement, we have the amount of disk space on a volume, we have the contents of a particular file folder. What happens to applications that look for disk free in the middle of a copy of a file folder with 50 files? What happens when you are copying a DVD into a folder? Do you lock the folder query while the DVD is writing?
You guys that admire SQL Server because of a few dozen tables and some little data sets (by little I mean less than 100,000,000 rows), have no idea what you are talking about. Database based file systems with transactions are madness.
This is my sig.
It's funny how many Mac zealots, when they want to put down Microsoft, claim how Microsoft never innovates. Yet, when the story on /. shows up that clearly points to the contrary, then they revert to their fail-safe backup approach -- they put it down as insignificant or useless.
/. Mac zealots rejoice and talk how it was in development long before Microsoftever dreamed of it (hence implying how Microsoft stole that one as well)...
In other news (2 years down the road), Apple releases a new SQL based FS that they claim as an original creation and all
Now, I do not claim that Msft did not "steal" ideas, just like anyone else in the greedy corporate world, but what disgusts me is this obvious dichotomous treatment of two companies which in their monopolistic behavior are almost identical (Apple with its price gauging and closed hardware, its misleading adds about the performance and claims about being "first to just about anything", and Msft with its proprietary "standards" and other numerous monopolistic and non-competitive behaviors).
It should be no surprise then to point out that I use Linux. Perhaps it's not the best or prettiest, but it sure has a bright future ahead of it and it is exciting to be a part of it. After all, time is on Linux's side (SCO and others like it do not concern me one bit, they will prolly claim chapter 7 before the end of this year if they continue with their crap)...
Q: When did you save it?
:-)
A: Yesterday afternoon
find . -name \*.jpg -mmin +1000 -mmin -1500 -print
I think your solution already exists
Windows loser talk.
/tmp being on a disk).
If you only knew about tempfs and other unix style strategies that help to avoid hitting swap (solaris uses unused memory in place of
What should they do, AlphaSys? Make a RAMdisk on one of these and put the "pagefile" on it?
The the problem with you is you never get technical nor offer any solutions or say anything of interest.
It's a joke, laugh.
Actually, we've tested quite a bit of the memory disk solutions here. Haven't really been able to get performance to justify the cost though.
Glad to see your Googlin's up to par, tho.
Can I bum a sig? I left mine at the office.
- Its not funny.
- You have never tested solid state anything
- I own a rocketdrive. You dont. Youve never used one.
Sorry to take so long to get back, but I was tring to find the info for *both* the kinds of SSD we've tried here. But I could only find the one. Funny, if you Google SSD, it'll be the first thing you'll find, so I'm sure you'll claim that's where I got it. It was the TMS RAM-SAN.
Can't seem to find the info on the other...it was like Armadillo Systems or something like that. Ultimately doesn't matter much. Didn't perform very well.
Can I bum a sig? I left mine at the office.
- I understand the latency. Fabricating a story is more intensive than reporting the truth.
- You don't have SSDs, liar.
- You can't find info because you dont have it.
- You comments on performance are lies because you never had an SSD.
How long would it take to Google "Solid-State Disk" and link the first company that comes up? Not long, I think. Maybe for you, but for humans...
Your ilk are the reason Bob Dobbs had to point out that the realm of subgenius is not simply the realm just beneath the genius but actually extends *far below* it.
Can I bum a sig? I left mine at the office.
Mod this up. The man has a valid point. Going by the last link I read on Longhorn, they'll eat GNOME/KDE for lunch and bring a quick end to the "Linux desktop revolution". Apparently the demonstrations given are workable, and that means that they have a good chance of getting onto the shelves in two years. There will be a lot of catching up to do if Linux is to stay in the mainstream after that.
- Liar.
- Your hubris is foul. You are a sad person. You are an arrogant, insecure jealous person who lies and lives vicariously and you have a small penis complex.
This really has nothing to do with user usability, performance, or anything else. The MPAA and RIAA are tired of having to wait for dir /s to finish (assuming they've hacked your computer) to figure out if you have any pirated music or movies. It's too slow to make it feasible to run scans of large numbers of computers. It's also quite noticeable to the user.
Give them a simple backdoor to access WinFS remotely on any computer (through some bill they push through congress soon after the release of LongHorn), and they can scan entire networks in a reasonable amount of time. Doesn't require them to run indexing software on your computer, since Microsoft has done it for them. Trivial application to write if WinFS is really based on SQL Server, one would imagine.
It's not just DRM boys and girls, it's easily enforceable DRM.
Hey, maybe they can use the "Messenger" Service that runs by default that does pop-up messages
Message from User 'YerFucked':
Click ok to pay us for the 1800 MP3's you've downloaded or click cancel and the police will be dispatched to your location. Thank you for your compliance.