Slashdot Mirror
Next Windows to Have New Filesystem
ocipio writes: "Microsoft is currently planning a new filesystem. Its planned that the new filesystem will make searches easier, faster, and more reliable. Windows will also be less likely to break, and easier to fix when it does. The new technology will cause practically all Microsoft products to be rewritten to take advantage of it. Called Object File System, OFS will be found in the next major Windows release, codenamed Longhorn. More information can be found here at CNET."
Yes, I'm cynical. But really, why shouldn't I?
:Peter
that they can simply take FFS and Soft Updates and embed it in Windows, and call it OFS.
Now that would be a substantial improvement.
political_news.c: warning: comparison is always true due to limited range of data type
I hope this doesn't cause as many problems as the last feature they added.
This is probably in response to open source software people finally
figuring out most of (the undocumented) NTFS. They don't want Linux,
*BSD, etc. to be able to read and write their filesystem easily, as that
would make it easier for people to dual-boot and/or migrate away from
Microsoft operating systems.
Note the historical sidebar on the article. It traces the on-again, off-again history of OFS. MS has been playing with it for over half a decade (!), and doesn't yet have anything to show for it. They've backpedalled and caught up again so many times that I think this article can be safely labelled as speculation.
In other words, it sounds cool. I'll believe it when I see it. (and only at that point judge whether it really makes Windows less likely to break)
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Check that you're not running an Office documents reindex. This is on by default and _despite_ the name, what it does is search every file your document pool and attempts to add it to the index. Very not recommended.
Yes, moving the documents _will_ stop this process, but it's not the most practical method is it? Better, by a long, long way, to turn off automatic indexing of office documents.
Cheers
Chris
no - afraid not. Unless pointing out that this will be a very proprietary new file system, that it will probably force everyone to get major (paid) upgrades, that it will intentionally be made to be incompatible with any other system.
To be honest, NTFS seems to be a tip-top file system to me. The only thing I can imgaine it missing is hardcore digital rights management (cant wait).
What a clever way to force DRM down every consumers throat: break every single windows program created prior to OFS.
fuckers.
(2,3-Benzopyrrole)
... my fat32 and NTFS seem to work okay... I dont think my concerns with microsoft are a result of their filesystems... this isnt a microsoft bash, I just think they would do better to focus their efforts elsewhere...
It looks like BeFS with XML descriptions instead of MIME types. I think.
[o]_O
You mean Microsoft finally figured out that NFS was the way to go? Oh wait, we can't call it NFS... A,B,C,D..N,O! We'll call it OFS!
*snort*
This is just because people finally figured out their so-secret NTFS.
Zaphod B
When duplication is outlawed, only outlaws will have
As an added bonus, entertainment pack 1 will include binaries required for recreational activities such as "OFS whacking". When asked to comment, Microsoft Spokesman v3.0 stated that 'whacking' without EP1 would invalidate the EULA and could result in system instability, a general sense of self-worthlessness, and pocket lint.
John Maynard Keynes: "When the facts change, I change my mind. What do you do?"
From the article:
Replacing its antiquated file system with modern database technology...
Now, if you were going to base a file system on a DB, what would you use? An Object-Oriented DB? Where organization is key (which you want for a file system), or a Relational DB for speed (which is why they are claiming to switch)?
I'm sure they are going to make a custom system, yes, but wouldn't it have to be based on one of the two major DB designs?
For the record, I'm no DB Admin, but, as I understand it, relational is the choice of DB for almost all projects for its sheer speed, OO is only good for academic reasons to show off organization...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
The GNOME project has an excellent overview of some of the issues with metatata in general.
Of course, this will mean a whole new found of application incompatibilities on Windows and a whole new round of reverse engineering to determine the filesystem and metadata layout.
Windows: Everything is an object
I guess it all comes down to whether they can make the surrounding environment rich enough that people can do everything they can do with objects as easily as they can with files (without writing a program).
My question is: am I allowed to bash them for recent past failings? I'm still doing major clean up, and since the entire registry was among those files that were forever lost, I'm still kind of bitter.
John
No, I turned off all that stuff (Office Startup, Indexer, etc.), and I have that Process Thingee from sysinternals.com running so I'm can say with certainty that I know what's running & what isn't.
It's really weird, and annoying, but it's worked on two of the Win98 boxes I've tried it on. (home & work).
[o]_O
Windows will also be less likely to break, and easier to fix when it does.
Doesn't MS say this about all the new versions of thier products ? Not that Windows hasn't improved, it certainly has, but they also never seem to live up to the hype.
Fascism should more properly be called corporatism, since it is the merger of state and corporate power - Benito Mussoli
From what I understand, Veritas essentially rewrote NTFS version 5 (shipped with win2000 and winXP) and
integrated built-in volume management (dynamic disks) with some abstract layer to maintain the clunky drive letter schemes.
I dont' really see the reasoning by mentioning that all Windows applications will require a rewrite; they only need to abstract the Win32::File APIs to handle the internal OFS changes... the changes that they document appear to do essentially what the Indexing services do for win2000 and winXP now. I assume it is just extra metadata strings that they associate with each file inode.
It seems a bit arrogant of MS to think they can improve (or trash and rewrite) what is essentially Veritas' domain, file systems. But then again, we're talking about MS...
Big brother is watching!
I don't see how this can be called a solution for reliability. Oh, I see, it will make searches more reliable... I am not sure how you can even make that statement? What is a reliable search? It will definately make backups more dificult. And, given the reliability of Exchange and the system registry, I'm not to sure I want all my files in any database, much less Microsoft's... I can only think MicroSoft wanted to boost sales of SQL Server, and this will do that. I wonder if you will then need a seperate SQL CAL to access content for what was once a fileserver?
How about some new slogans for MCSE's:
Beware the flat file!
Flat files are the cockroaches of the OS!
I have come to a conclusion that one useless man is a shame, two is a law firm, and three or more is a congress -J Adams
Everyone would have to buy new versions of all their office software! Isn't that handy for MS?
I'll pass. I may be running (pre-installed) XP on my Dell but I'm still using Office 97. Why?
BECAUSE IT WORKS JUST FINE.
I don't need to "upgrade" to something even more bloated and bug ridden.
How long do ./ readers think it will be until the Linux kernel and/or Samba will be able to read OFS shares?
So by Microsoftie troll logic it was your fault for not having a UPS on your machine. Or buggy drivers, take your pick.
occurs 20 times in the article. As in:
But the benefits, if they succeed, will be huge.
"We're sorry, but the website you're trying to reach has been disconnected."
I remember MS talking about this years ago, even before NT came out. They were calling it Cairo back then.
In the end, IIRC, the UI elements of the Cairo project were recycled into the Windows 95 shell and the Object File System concept disappeared entirely... until now, it seems.
Is no-one else disturbed at the short memories in the industry? I was at the launch of Visual Studio.NET in Ireland a few weeks back and there was a Microsoft goon waving a Tablet PC around his head like it was some completely new thing. I mentioned the Go Corp/ Windows for Pen Computing FUD from the early '90s to the guys I was there with and was met with blank stares.
How much do you want to bet this breaks samba. How much do you want to bet that Microsoft won't release enough information for the samba team to quickly support the new file system. How much do you want to bet this has nothing to do with making a better file system and more to do with killing non-Microsoft servers. I would give any other company the benefit of the doubt. Microsoft's history, however, proves everything they do is to increase marketshare and nothing to do with making a better OS.
-- Will program for bandwidth
Gimme a D, gimme a R, gimme an M. . . /. ads ;)
What's it spell?
I also see my ad filter is working on the new
1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcf
Rather a good thing to know.
dinner: it's what's for beer
I hope any changes that happen to the file system also include the removal of the antiquated concept of file extensions for type association. Here is another thing that Mac does very well. Imbed the type of a file IN the file. Why not give me a version number and some way to know what program created it.
Back to the original topic, I can't wait for an OFS. Just for my MP3's. Figuring out which folder hierarchy to use for genre/group/album/track is a pain. Let the file system group them for me.
A speech...
How can the storage medium be in any way involved in DRM? If you can crack a DRM scheme based on an HD serial number, why cann't you do the same for a DB-based DRM?
and the FAT32 took a major hit.
XP is an NT-based OS...why were you using FAT32 at all when NTFS is available?
C-X C-S
I hope they haven't discovered the unified file system, something which all the unixes use to store their data. We might be looking at the demise of unix!
oh wait, where do we put Progra~1 then?
- runs away to see if it's patentable
Yes, you are a troll. Is it wrong for Microsoft to advance File systems and state specific reasons and right to preach about the many choices in file systems linux/unix has?
When your talking
Say when you open a folder of 5,000+ mp3's and it searches the ID3 tags of every song and displays artist/title as part of the description, having an optimized file system for quicker searches of data on the disk will only streamline this more.
so yes, this is cool, and yes, there is alot more then just "fast searches" as you put it.
Looks like it's taking a team of MS developers years o do what one guy at Be (Dominic Giampaolo) did in very little time ;)
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
... right before the sledgehammer hits.
You can achieve this goal by the following process:
1. Store all of your documents in a simple, text based format, and not in some overly complex propriatary format such as ".DOC", ".PDF", etc.
1. This text based format is known as "American Standard Code for Information Interchange" (AKA "ASCII")
2. If you require more complex presentation of information, you might want to use something called HyperText Markup Language. (Which doesn't do much markup these days... but I digress)
3. There is a program built in to Windows 98 and above called "Find" (usually accessed by hitting F3), and in other environments known as "grep" which can search by content.
Use the tools you have, you won't have to "upgrade" to the latest bugs, and the computer remains useful.
--Mike--
How can the storage medium be in any way involved in DRM?
User: "Hey, an MP3! Save it to disk!"
Storage Medium: "FILE ERROR!"
"The market alone cannot provide sufficient constraints on corporation's penchant to cause harm." -- Joel Bakan
>Windows are working new ideas into their OS
.. innovation for innovations sake (or to tighen a noose lower in a codebase) isn't innovation at all.
Two questions:
1. How many FS types can you use in Linux? vs. Windows?
2. How much you wanna bet that rolling out a new FS is a clever way of putting DRM at the FS layer? Fun fun fun.
MS only innovates if it makes them money. Linux innovates when its useful, practical, or feasible. Don't get confused
"Old man yells at systemd"
They should have it working by the second service pack or so.
I remembe reading about this (on slashdot?) when longhorn was first announced. From what I understand programs need not be rewritten to take full advantage of the FS, though might gain a little bit if tuned for it.
The FS is essentially a giant database, and thus all of the good search algorithms and recovery tools written for databases can be applied to the Filesystem.
But then again, given my experiences with MSSQL, perhaps they should just keep NTFS 5 and remove the 'alternative streams' and make junction points take UNC names.
Early versions of BeOS had a full object orientated file system and found performance was abysmal. This was from a company with no backwards compatibility to worry about and a small OS designed for speed.
In the end Be developed BFS which is basically a standard file system with support for indexes and attributes, an overall much better performing system with most of the benefits of an object orientated file system.
[)amien
Refreshing to see an MS news item that has no bashing in it what-so-ever. How about we keep the discussion mature, also?
I think you missed the implied sarcasm.
[user] Open Excel document "Personal_Finances"
[windows] Please log into Passport so the $0.50 file usage fee can be charged to your credit card.
[user] But this is my file, I created it.
[windows] NO, I store your crap file, it is mine.
[user] THAT's IT, I'm formatting you!!
[windows] Please log into Passport so the $999.99 reformatting fee can be charged to your credit card
[windows] And have a nice day!
-- Find the Truth...
A problem I'd really like to be solved is the way that file extensions are registered (and then fought over by programs). Granted, this is in some part the fault of software companies (cough, real, cough), but if a more elegant solution existed to that sort of mess, then maybe it wouldn't be so annoying. I would equate that to if a program of mine that ran ".dum" files found and deleted shortcuts to other programs that ran ".dum" files -- and that's just unacceptable.
Down with MS? Nah, but the benefits listed here of an new FS don't seem to justify its cost (having to reprogram everything to take advantage of it... ouch!).
-Sou|cuttr
Having someone else read it for you and post a summary or an excerpt is better.
Does that mean I have to stop running findfast.exe to speed up my file searches!? I can hardly believe MS thinks they can come up with something better than that little gem of an app.
-Pete
Soccer Goal Plans
Be sure to check out my page linking the chief SW architect at Msft with the mascot of MAD Magazine.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Hey trollie, read the article. Or better yet, the Slashdot posting. This file system has nothing to do with DRM.
.. boy, don't even get me started on that.
Firstly, there is no such thing as "Microsoft Digital Rights Management Software" (Media Player supports DRM, but only for WMA's) and Microsoft has nothing what-so-ever to gain from including DRM features into the file system. They know and we know that Longhorn with DRM will go down the toilet, while Longhorn without DRM will sell just as well as WinXP, probably better.
The second thing you got wrong is that this system is not (just) about speeding up searches. It's about replacing an antiquated system that's been around since MS-DOS with something future-proof, faster, and more reliable. Considering they've been working on this for 10+ years, they'll probably succeed eventually. And when they do
Now, for something constructive. When will we see this in Linux? Surely, if Microsoft can do this, so can the people working on Linux. Riiight?
Quality, performance, value; you get only two, and you don't always get to pick.
Everyone would have to buy new versions of all their office software!
Ummm...Why?
Changing the FS would really only affect the way the data is stored on the drive, the AppFS interface should be abstracted by the OS.
C-X C-S
Maybe the rest of the world has a short memory, but I don't.
According to what Microsoft had announced some time ago, they are HALTING further new development while they focus on bug fixes. Can I then take this as a sign they've fixed all the problems with Windows?
So now they are working on new developments again? I'm pretty sure existing Windows is not completely stabiized...I know mine isn't. So what does it mean? Micrsoft can't maintain focus? They can't tell the truth? What?
Now for some speculation. The implementation is likely to be based on the same "pluggable" FS driver architecture first introduced in Windows 2000, where the NTFS and FAT32 drivers are just a layer on top of the kernel (you can actually buy a devkit from Microsoft that will allow you to implement, say, ReiserFS for Windows 200). This however poses an interesting question: do you make this newfangled FS to sit on top of tried-and-true NTFS, or do you implement it at the kernel level and make NTFS a layer on top of that? Either way, I think the article is overstating the devastating effect on existing apps. Microsoft is not about to shoot itself in the foot so massively. Whatever this ends up being it's a good bet it will be fully backwards compatible. Kinda like Win32, which can still run 16-bit apps, albeit slower (in 2K and XP). But this will make companies more likely to either port existing code or release newer versions that take advantage of the redesigned FS.
There's a interesting Register article here
It really is an interesting problem. My Wife's iMac only has a 6Gb drive. She's always saving info form the web into AppleWorks files. She has generating a LOT of little itty bitty files. Now our PC file server stores our digital photos and mp3s, and both iTunes and iPhoto make managing that mess quite easy and Sherlock is SUPPOSED to make finding in files easier (it kinda does), but does a poor job at it.
Now, my point is, I've actually thought about setting up some form of database so that my Wife can find her info for years to come. But my biggest question is NOT would a database help, I'm sure it would. What I would like to know, is how would the interface for that database look?
Considering what I have seen of XP (I got a copy sitting on a 2GB drive that sits on my shelf), MS knows very little about information management in the UI, and I would expect this problem to not get any better for the majority of PC uses, even if the entire file system was one big database.
Burn Hollywood Burn
I just look at the microsoft record where the 1.0 version of anything was not very good. Just look at the version one point oh of any of the name products. windows, word, excel, etc etc etc. This with their initiative to have "trustworthy" computing is going to present a major problem.
One of thesetimes they are going to try to retransformed themselves on time too many and it will blow up in their faces.
I deem to remember an article (and an extensive Microsoft whitepare, etc)from about a year ago. I don't remember if it is the same thing. (can't find the link right off)
"It is a greater offense to steal men's labor, than their clothes"
While they are dinking around with the file system they will most certainly change the way the SMB works. What is the purpose of having all of these spiffy new features in a file system that can't be "exposed" to other machines as shares?
NTFS has been a journaling file system similar to those for a very long time. Linux was the one playing catchup on that end.
The point of this new data store isn't necessarily faster searches, although that is one part of it. The idea is to have a common data storage mechanism, used by all programs.
The underlying technology is to replace the NTFS filesystem driver with SQL Server, with a few tweaks. SQL Server already supports using a RAW partition as a data store, so essentially you just have to move the transaction log and descriptive info for the databases into a specific area of the disk. Add a little bit of bootstrap code to ntldr, and slap the SQL Server stuff into the startup driver list, and it's a done deal.
The next step is creating an NTFS compatibility layer -- it would allow you to mount tables as drive letters or network shares. A lot of the information wouldn't be useful when viewed in that fashion, but it would give you a way to run older programs.
Once all your data is in a common data store and can be manipulated as such, it opens up a world of new possibilities. The change will be long and slow; no need to kid about that. It will take years for all the 3rd party programs (and even Microsoft's own apps) to catch up and start taking full advantage of it. It's the same situation Plug & Play was in back in 1995; it sorta worked sometimes, but you couldn't really take full advantage of it. But here in 2002, you really can expect to grab a piece of hardware and slap it in your box without hassles. It took some time, but it eventually paid off.
But... are you having trouble, as I did, thinking of ways to make use of this common data store? Part of that comes from the fact that we've been conditioned and trained to think of data storage in terms of files; it's hard to shift gears... to think outside of the "filesystem" box so to speak.
For one thing, I could see someone emailing me a project. Not some word documents, an excel spreadsheet, and a database zipped into a ZIP file; they just email me the project. When I get it, and open the message, the project opens up presenting me with the various documents (linked to the database of phone numbers for example), and a little yellow stickynote window that has the project leader's actual email text. I didn't have to deal with unzipping the data, rearranging it, then opening the documents separately. Since the "rows" are linked, they open and act as a unit until I tell them to do otherwise.
It gets better though... imagine if I could run a query such as "SELECT f.*, s.filename FROM Folder1 f INNER JOIN folder2 s ON f.datetime = s.datetime"
It can get even more useful because you now have full SQL syntax available to you for manipulating the filesystem, with queries that are lightning fast. Throw in some Stored Procedures, Functions, Views, etc and I can see real possibilities.
Natural != (nontoxic || beneficial)
And IBM's AS400's have been doing this for years. Not to mention BeOS. ReiserFS is of perticular intrest because it will allow for attaching of arbitrary objects to any node. Only problem is we have five next generation file systems duking it out so generic Linux will most likely not see the benifits for some time as nobody will want to program specificly for a filesystem that reaches only a fraction of the usebase. It would be sure nice though to not to have to see .nautilus-metafile.xml stewn about my file system. sigh! What would be nice is generic system calls for filesystem metadata that would write out .nautilus-metafile's for FS that don't support metadata and node metadata for FS's that do. Of course we would need a standard format but it would be instantly useful.
Why fuck with the file system? Why not
just use a database in the first place?
There doesn't seem a reason to have file
system semantics for this sort of thing.
Especially when there are so many database
tools in place.
The submission form is acting weird so here is the link again: http://www.pbs.org/cringely/pulpit/pulpit20010802. html.
This New File system sounds to me like something similar.
Having lived now through, 15 years of Microsoft ... The one thing I know for sure is: Microsoft always anounces some ground-breaking technology thats going to make everything so great... Then when you finally get the product in your hand -- its the same damn thing exactly as you had before.
Every last program in the world is based on block IO (and dont tell me about streams they're an abstraction of block IO). Whatever they do, it *has* to be compatible with standard file handling semantics WriteFile in Win32s, FILE in C, fstream in C++, open in python etc...
So really the only software using this fancy dancy shit will be MS's own programs... The last thing programmers want is some new and horrible way to access files.
Lastly, remember who this is article is coming from -- CNET, the unabashed supporters of MS. If MS shit in a box (which they pretty much did with win ME) CNET would still love it.
Religion is a gateway psychosis. -- Dave Foley
They proved with AS/400 that using a DB for the file system was the way to go. It's too bad they did it way ahead of their time.
I'm personally glad MS is finally changing their OS. Now that my workstation has 70GB of files, searches are taking an incredibly long time.
I have less than 100,000 files on my workstation. Each has maybe 10 searchable attributes. A full search on this can take over five minutes. (Athlon 800Mhz w/ 7200 RPM IBM drives on a Promise controller)
I know from experience that querying an Oracle database (on a cheap 500mhz linux box) on 100,000 records with 30 non-indexed columns/attributes generally takes around 2-3 seconds.
Imagine if MS were able to build a file system with such capabilities.
> They want to get their Digital Rights
.NET and start dropping the crufty Win16-contaminated Win32 API and x86 ties.
> Management Software to infest every aspect of
> their OS as possible.
Right. You keep throwing your FUD about while the rest of us looks at things seriously.
> Do you honestly believe that the benifit of a
> faster search is enough incentive to rewrite
> such a major part of the OS?
Short Answer: Yes.
Long Answer: Filesystems haven't changed much in the past few decades, but one of the things they have tended to gain is arbitrary metadata. Adding indexing to that metadata is a natural progression of that.
Now your filenames are just a part of the metadata you'll want to play with different views of the system, which suddenly becomes much much cheaper. Believe it or not, lots of users have trouble understanding the current basic filesystem concepts and using them to organise their data; well, now you can do it automatically for them.
Of course, you want your other stuff to make use of these new ways of looking at the system, especially when you're MS and are running out of new features to put in (come on, what are they going to add to Word XP now? A paperclip with speech recognition? Yet another GUI redesign?), so you want to do something that provides a visible difference (and maybe even an advantage) for those expensive upgrade programmes.
So, yes, I think they do have a very good reason for such a major change, like they had good reason to introduce '95 and start dropping DOS, or NT and start dropping Win16, or
The biggest issue I have with it is that it's going to be a bitch to use in other OS's. Hopefully they'll do detailed specs and stick to them fairly closely (ah haha), which will at least make it easier.
Everthing is a file, says Unix.
But that was 30 years ago. Perhaps its time to extend the unix-doctrin: Everthing is a file and a directory.
Why? Metadata.
Todays file-formats store informations about the file inside the file (thing id3-tags) or abuse file-attributes (such as the filename(.html)).
With files as file and directory, there would be no need for that. Imagine: you store informations about the authors of a file inside metadata-attributes. There would be simple possibilities to search for these informations, so one could easy pick up all "draft" files inside a direcory (ls -al *../status=draft, maybe)
p.
NTFS is a very solid filesystem and seems to recover problems well when something bad does happen. The only complaints I have are slow searches and reports. It takes a LONG time to find a file on a big volume, or try and do reports on file system usage. A good database system should speed that up tremendously.
The idea of having to rewrite the apps is interesting though. That tells me this is at least 5 years off, and longer before it would be used widescale. But I guess that makes sense, would you be the first shop to put your big fileserver on a new filesystem like that? Not me.
does this mean they'll finally manage to have TYPE and CREATOR code metadata so you can name a file what you want, and it'll still work if you forget to put
In the process, the plan could boost Microsoft's high-profile .Net Web services plan and pave the way to enter new markets for document management and portal software, while simultaneously dealing a blow to competitors."
OK I know FAT is antiquated, but NTFS is modern. In fact I recall it was announced at some point 3-4 years ago that OFS wasn't necessary because all the relevant features were being merged into NTFS? Maybe that was an internal announcement, one of the annual "we are finally merging our data stores" emails the top Microsoft brass would send out to the troops.
Anyway I don't see why this would make Windows less likely to break or easier to fix, or what it has to do with .NET...why does that kind of marketing fluff have to be included in a pretty reasonable article (and the sidebar is very nice)?
- adam
They should call it FS.net and when bundled with Outlook Express, makes Windows the ultimate in File/Email Sharing technology.
can't sleep slashdot will eat me
It's funny that microsoft is working on a filesystem to 'help users find stuff faster' when they have been so adamant about hiding the file system from users for quite awhile.
So they are incorporating the work of Hans Reiser~! Great idea MS! Perhaps slip in some DRM, maybe some NSA features as long as they are continuing to appropiate everyone else's ideas
No, they can't be doing that because as Hans Reiser claims, you can't do that kind of filesystem without modifying the NT kernel[1].
This idea has been around Microsoft since 1994 at least... possibly earlier. It was the whole idea behind the Cairo project.
Simon
[1] Personally, I think he's on crack with that statement, but hey, if he wants to go ahead and sue Microsoft (he claimed as much on the AM-Info mailing list) to get his filesystem working on Windows because he doesn't understand how to write a filesystem driver for Windows, then he can go ahead.
Coming soon - pyrogyra
Who got the hairbrained idea that having file metadata was superior???
Sure its great for marking a file as executable or not, instead of having the OS itself guess based upon the name.
But for documents, if all the type information is stuck away inside some metadata, then what happens when you transfer a file over FTP? do you have to guess what type of file it is?
What about the output of a pipe or socket? How does my PDF generator know tha "output.pdf" needs to have its metadata set to some damn obnoxious xml snippet? Is the file unusable until someone does that?
And its not like you can have different files with the same name having only different metadata. I cant have "temp/document.txt" and "temp/document.rtf" because they would be "temp/document" (ambiguous) to a shell script.
And what the hell does a version number mean? Does it have the same meaning for a word document as it does for a Makefile as it does for a device driver? Then why should they be stored the same?
Im not a big fan of MS's retarded implementation of OS enforced extensions, but I do think that filename extension are here to stay because they work better.
A file is a file, and the extension is just a hint on what to do with it, or what it might contain.
And if you want to sort your MP3's, there is this nice thing called Id3 tags, you might want to look into it...
...that software companies, instead of having to support two different file systems will now have to support THREE different file systems otherwise they will loose clients. I can't see how Microsoft expects to slide the entire paridigm of what they've created out from everyone and think that everyone will come along for the ride. Face it: Older versions of MS products will be out there for a LONG time, regardless of what Uncle Bill wants...But, maybe that's their plan? Force all the smaller companies out of business! Microsoft products for everyone!
"But Judge, really, we're not a monopoly....those other software developers just couldn't keep up with our new innovations...."
It is funny, we accuse Microsoft of using other people's ideas - but are we really any better? How much of Open Source development is really just reimplementations of other people's ideas?
Bogus comment. It's perfectly comprehensible -- although Ballmer's answer could have been simplified to, "We hope not."
Only the dead have seen the end of war.
I just have this feeling that completely replacing the file system can't make it less likely to break. I've had no trouble with FAT32, and I seriously doubt MS's ability to write a filesystem that has no bugs. But maybe I'm just being pessimistic today.
Exactly. NTFS is a great filesystem all in all, and I haven't lost a single file ever due to powerloss or similar. I would dare pulling the cord from the back of my computer while it's running. Would you dare that with ext2? You say you run XFS/ReiserFS/etc instead? Go figure...
I'm surprised nobody's posted this yet, but ReiserFS is working on something similar, described in this whitepaper.
When I read this article, I immediately had two thoughts:
Thought 1: "You know, they're right" Current file systems are outdated and are not really serving the needs of modern applications. Take for example, Microsoft Outlook (and Outlook Express). The programming teams for these pieces of software were forced to implement a "filesystem within a file" in order to achieve their design goals (I believe the files are called DBX files). Or take for instance, the Windows Registry, or, even better, the Gnome registry, GConf. Why do programmers have to implement dozens of different abstract filesystems in order to achieve their design goals? Simple, the present filesystems are not sufficient.
Thought 2: "Another way of attacking the Free Software Movement." By creating a new filesystem, Microsoft achieves many goals. First, they make Linux filesystem developers start from scratch again. I mean, the NTFS driver isn't even done, and this means we would have to start over. It gets even worse: From the sound of this article, it seems that OFS would be fundamentally incompatible with our conception of a filesystem today (possibly including features such as resource branches, GUID tags, and other metadata forks, ad nauseum). This would make it difficult to write a usable Linux driver for OFS. And finally, to top it off, my gut tells me that the POSIX file access calls would _not_ be sufficient to access such a rich filesystem. The introduction of a new, richer file access API by Microsoft would make writing cross-platform software much more difficult.
Microsoft can kill two birds with one stone here.
Ben
Nearly fifty percent of all graduates come from the bottom half of the class!
The SQL server files have to be on a "file system".. so what's THAT going to be?
Not if your database server has its own datastore functionality built in -- and many do. You know how Oracle can work with raw partitions directly? Think 'bout that kind of functionality, just done by MS.
Those with good memory will remember that Microsoft was promising something like this about 10 years ago. Don't hold your breath.
Granted alot of things are wrong with it but NTFS,in general, works. This DB file system just makes me wonder. With fast hard drives becoming the norm, it doesn't take that long to scan a disk. Linux has locate and other file indexers to assist in searching the hard drive. I mean I HOPE there better be some other reason to do this because it doesn't make sense. To me, it seems that this DB would add overhead to the whole thing and of course require more CPU, Memory and disk space. How about just fix the bad stuff in NTFS Microsoft. Also, those who have a clue don't really need to do file searches because we usually know where all of the important stuff is. That's not saying I don't want that feature, it's just that adding that soley for increasing search speeds seems like over kill to me. Again there may be other benefits to this OFS, but they had better be more substantial then just faster file searches.
Gorkman
If you take a look at the XP interface, it feels (to me at least) a lot like a candied up BeOS -- a lot of the icons have a similar look, there's the grouped taskbar items a la the BeOS tracker, etc. And seeing as BeOS has been around for years, it makes a lot more sense that the Microsoft engineers would have been able to start reimplementing ideas like this by this point.
And now we start seeing articles like this one, and it becomes clear that just as the XP interface has started to resemble BeOS, the XP native filesystem is starting to resemble BFS. This isn't the first time in recent months that we've seen reports of this -- not long ago there were articles saying that MS wanted to ditch Access and it's Jet engine (or whatever it runs now), and turn the SQLServer engine into the core of the next generation filesystem. This is of course exactly what Be wanted to do, but couldn't due to performance constraints, so they went with the scaled back object oriented system instead. Hey look at that, now we hear that Microsoft is also going with an OO-FS instead of a full SQL-FS.
Microsoft already ran Be out of the market, and are rightfully getting sued now for doing so. I wonder if Be would be willing to use this increasingly familiar evolution for Windows as evidence that Microsoft wanted to eliminate their strongest OS competition while ripping off all their good ideas. As much as it's vindicating to see that BeOS's best features will live on in new versions of Windows, I'd rather have the chance to see the original around today...
DO NOT LEAVE IT IS NOT REAL
-Pat
Look at it this way - some of us may wish that the whole world used Linux, but it doesn't. It uses Windows. So when MS announces that they're taking a big risk (and it is a big risk) to try and make such an enormous upgrade to Windows, I think we should be happy that a few years down the road, if Windows is still dominant then at least people will be benefiting from this technology.
But ... this doesn't mean we should just sit back and go - well done Microsoft! After all, I recall reading about something similar over at the reiserFS page... how long until Linux users get this technology also?
maybe because just about any other OS you would dual boot into, can read AND WRITE to fat32. Using win2k, I use NTFS for the program junk, but have a fat 32 partition for the pile of stuff I use between Win2k and FreeBSD.
That's what they said about the registry. It will solve all of the problems with ini files.
But as everyone knows, with totally undisaplined usage of the registry, the registry is a nightmare. In some cases it is impossible to clean it up and the only solution is a reinstall.
Ask any dba. Even with the most heavy duty industrial strength db, somebody can come up with a schema and application that will bring that db to its knees. Prepare for deja vu.
[user] Meet my friends Mr. Debian Boot Disk and Mr. Debian Root Disk
[windows] A priority alert has been dispatched to the BSA.
[Debian Boot Disk] So Boss, do ya want to just rough him up a little or completely murdalize the bum?
*shrug*
It's their money. If they believe that they can afford to work on it, why not?
Only the dead have seen the end of war.
Lets get things straight here.
There is no point of comparision between regular filesystens, and journaled ones. It's not a matter of Win x Linux. I would not dare pull the power cord of a ext2 based computer, but I would do it on a ext3 based one. And what is ext3 besides adding journaling capabilities to ext2 ?
You see, journaling filesystems are all slower than regular ones. Of course, I new developted journaled fs tends to be faster the a filesystem developed 20 years ago (usualy).
On the other hand, it's still possible to lose data on a journaled fs. Not as likely as in a regular one, so don't trust it too much. It's the worst thing you can do.
morcego
"We've been working hard on the next file system for years [since the early 1990's], and -- not that we've made the progress that we've wanted to -- we're at it again," Ballmer said.
While the Cairo project eventually resulted in Microsoft's Windows 2000 operating system, the file system work was abandoned because of complexity, market forces and internal bickering. "It never went away. We just had other things that needed to be done," Jim Allchin, the group vice president in charge of Windows development, told News.com.
Those other things most likely included battling "Netscape and Java and the challenge of the Internet and the Department of Justice," Gartner Group analyst David Smith said--issues that continue to persist today.
<snip>
The more important reasons for the renewed development effort, however, are strategic. If the plan succeeds, it will give Microsoft a huge technological advantage over the competition by making its products more attractive to buyers and giving large companies another reason to install Windows-based servers.
So if they hadn't been trying so hard to kill off Netscape, they would have had the time to spend on creating this. Something that seems to offer actual advantages to the user, and that would be "a huge technological advantage over the competition by making its products more attractive to buyers."
I wonder how many other genuine advances have been put on hold in the name of detroying someone else first.
Nope, no sig
I wonder if M$ will fall into line with the RIAA and MPAA and implement some sort of DRM scheme on this filesystem. I wouldn't be the least bit surprised.
"You done taken a wrong turn."
-Bill McKinney, in Deliverance
Amazing magic tricks
User: "Hey, an MP3! Save it to disk!"
Storage Medium: "FILE ERROR!"
User: WTF? emusic.com and mp3.com [1] don't work. Let me try this "Man-drake" thing I keep hearing about from my friends. *format*
If Microsoft breaks Windows's file system in such a way as to kill popular and legitimate applications, the effects can only be spelled S-U-I-C-I-D-E.
[1] Two popular sources of legit MP3s.
Will I retire or break 10K?
Actually, I had my spouse turn my Linux box off as standard practice for months without any ill effects. She did this because she still used WinDOS and didn't want to be "inconvenienced" with a proper system shutdown.
With Linux, it's not quite so much the underlying filesystem as it is the fact that you aren't trying to run a pathetically fragile database engine (windows registry).
If files aren't open, there is no reason you should expect them to implode.
A Pirate and a Puritan look the same on a balance sheet.
As I see it the file system is for storing files and a *small* amount of system-related information about those files.
.xyz without making the filesystem so complicated and non-portable.
The need for metadata seems to be centered much higher in the system, at the user or application level, not at the filesystem level. I think that the best way to do this would be to implement a file(1) into the system that other applications (file manager, desktop GUI, applications) could use to determine what a file is.
Most files have header information in them anyway that describes the file's information in pretty great detail to begin with, and this and the way the data is structured can be more informative to the user or an application than either
I know Oracle will take raw disks... won't SQL Server 2000?
In any case, raw disk access is nothing new. The implications for IDE drivers, however, would be interesting. You'd basically have to write the driver for SQL Server and read it with direct hardware.
I don't think 7.0 does this, but I could always check.
If you mean: when will Linux-folk create a better file system than currently existing file systems? The answer is now. There are any number of folks working on newer, better file systems today.
If you mean: When will Linux-folk create software that can read from and write to Microsoft's new FS? The asnwer is: a long time after Microsoft finishes OFS. If Microsoft can do it, then yes, so can anyone else.
But, you must remember: once Microsoft is done creating OFS, it will take a good while for a good number of good people to reverse engineer OFS to a point where you can have good Linux-based code for OFS i/o.
I imagine only Microsoft Partners will get the info needed to make their products compatible. And they'll just get some API or something. I can't think of any reason Microsoft would give anyone outside the full specs.
Don't think for a second Microsoft is going to publish the full specs to OFS for anyone else to mimic.
Crikey, symlinks have been around for ages ('82?). How can MS say they have a modern FS without these?
Don't tell me short cuts are equivalent to symlinks. They are a veneer on top of the OS. They are not transparent as symlinks are on UNIX to programs that don't know about symlinks.
Yes actually I would dare that with ext2.
I have infact "dared that" with ext2 as regular practice over some months.
Linux as a desktop platform simply doesn't do the sort of extra bullshit behind the scenes that makes "extra journaling" a good idea.
I even "dared that" with FAT16 before Win9x came along. Win95 & NT merely introduced a toy database into the mix that doesn't provide good enough disaster recovery of it's own.
A Pirate and a Puritan look the same on a balance sheet.
especially since it's illegal to figure out anything but what they tell you
This applies to Microsoft too. The DMCA (17 USC 1201(i)) permits circumvention of measures that collect a user's personal information. If Windows Media Player begins to phone home too much, a decent lawyer will note subsection (i), and any rational judge throw the DMCA out the window for that case.
Will I retire or break 10K?
you couldn't delete it or anything? even as administrator?
Anything that's in the cache during the outtage is likely going to be lost. This is to be expected. However, you can design systems and software to minimize the likelihood that something critical is being written to at a particular moment.
This is what RDBMS servers do.
A Pirate and a Puritan look the same on a balance sheet.
Umm, no, but I do believe that releasing an OS that introduces incompatibilities with older versions of Office and Outlook will "encourage" the last holdouts against software-as-a-service to hand over their credit card numbers and jump on the bandwagon.
I'd expect to see the new OS provide goodies for those getting .NET Office and Outlook upgrades along with it, and to retain backwards compatibility for standard Win32 API apps, but with reduced speed and reliability. They'll just annoy us into upgrading those pesky old apps that we very selfishly bought unlimited time licenses for. Damn us and our luddite 20th century ways.
I believe it's just general low grade evil rather than anything more sinister. I do agree that a DRM mechanism will appear at the Windows OS level sooner or later, regardless of whether the SSSCA sneaks through or not, but I think that's a separate issue.
If you were blocking sigs, you wouldn't have to read this.
that we've obsoleted all our programming languages (and all programs developed with them, since they likely won't compile anymore), we'll obsolete all the existing programs too by making sure they won't work with the new file system.
Sounds great.
Except, of course, for being the only legal operating system when SSSCA passes.
Except, of course, for being able to extract royalties from every competitor because it has a patent on a "DRM OS".
> It's about replacing an antiquated system that's been around since MS-DOS with something future-proof, faster, and more reliable.
Sure, FAT16 and FAT32 sucked ass (but were great for interoperability), and NTFS is OK, and yeah, there are benefits to having more ability to manipulate metadata at the OS level - the example of running WinAMP and scanning 5000 ID3 tags being a great one.
But don't kid yourself into believing that there won't be more than just benefits with a new filesystem designed by MS. Their track record says it. Their future plans as in the Hallowe'en Documents say it. Their patent filings and current legislative environment constitute evidence that things are going to plan in Redmond.
To put it another way, XP is a "better" OS than 9x. But for my gaming/MP3/movie box, I still run 9x, because 9x doesn't come with spyware and nagware. (And for my real box, I no longer run M$ware). I suspect that Longhorn will be to XP what XP was to 9x.
Some people are willing to do without the perceived "benefits" of an upgrade because sometimes some things come at too high a price.
Depends. I almost get the impression they want to make the data entirely self-describing (think XML)
M$ can't make the data entirely self-describing. If M$ did, each document would contain a DOCTYPE that points to the specification of the format, and Microsoft would no longer be able to lock Office users into Office.
Will I retire or break 10K?
The "administrator" on a Windows box gets "permission denied" messages all the time.
Kinda makes the whole concept of "administrator" rather academic.
Faster Searches If someone thinks that their search needs to take 10 seconds less, what is wrong with the current Indexing Service that is in win2k/xp?
More Comprehensive Searches Why not have the current search program be able to read more file formats than just simple text files. There is no reason to force a database on the system.
Windows is less likely to break Why would I believe that? That has been said about every version of windows. I believe that with a newer OS, there will just be a newer set of bugs for MS to [hide from public]/[deal with]. Programmers make mistakes. It has also been shown that you can't test non-trivial code for absolute correctness. Windows will always break in one way or another, just like any other piece of code, except that we must continue to rely on MS for the fixes.
Indiscriminant Rants
I agree, but the only I see to really allow for good backwards compatibility while simultaneously allowing for new features would be maybe have the document file carry two copies of the document, one formatted in a way that the older one can read, and another with all the pretty formatting when needed.
Yes. Place all the *text* of the document in one area and the styles in another. (SimpleText on Mac OS 7.5 through 9.x did this.) Then you can go in with fscking Notepad (which doesn't have the 32 KB restriction under NT systems) and recover the text.
Will I retire or break 10K?
Copying features from IBM, Oracle and Be isn't innovating either.
A Pirate and a Puritan look the same on a balance sheet.
> And that's just for Office
>
That's right, you'll need to buy a new PC with a 1T hard drive, and 1G of RAM so you can actually boot the new Microsoft Windows OS.
I personally think that Microsoft can't fix all the security holes in it's OS's and apps so they are testing the market for what will allow them another 3-5 years of delays. The masters of "just wait til the next version" will keep those dumb corporate and government IT people strung along long enough for a rewrite of MS Office (more incompatibilities) and the stablizing of MS Windows (via componentization).
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Does "OFS" constitute a tacit admission that NTFS wasn't the best thing since sliced bread, but only a retread of DEC's Files-11 filesystem, and that NTFS had all the problems systemic to Files-11, like needing defragmentation?
Or is this just another instance of MSFT using it's monopoly power to screw over people who have bothered to reverse-engineer and implement a "de facto standard" like CIFS and SMB?
I really don't see how any rational being could interpret OFS as any other alternative.
Since MSFT did a half-assed job of copying Mach when they developed NT, they should take a look at Jeff Mogul's doctoral dissertation, "Represeting Information About Files": J. Mogul. Representing information about files. In Proc. 4th International Conference on Distributed Computing Systems, pages 432-439. IEEE, May, 1984.. Maybe MSFT can read this and get it right, instead of half-assing it like 8.3 file names, drive letters, NetBIOS, NTFS, NT, and many other examples.
A lot of people seem to've totally missed the point of what would be different about a database-oriented filesystem. File extensions? Not bloody well relevant! Let's consider the issue of searching. A database-oriented filesystem might allow you to create directories that are basically "views" of your filesystem, perhaps including all files that meet certain name, attribute or content criteria (like Evolution's vFolders but available to any app). These views would be up-to-the-instant accurate at all times, with no dead links and no problem with apps replacing links with actual files instead of updating the file that the link pointed to. Filesystems could also benefit from other things like referential-integrity checks, triggers, and cross-file transactional behavior. In fact, there has been a lot of work in the kernel-hacker community to figure out how just that last feature could be added to Linux filesystems. Basing a filesystem on a database also allows you to leverage all of the tools (e.g. efficient snapshots and replication) that have been developed for the database. There's a lot more here than just journaling and BeOS-style metadata.
It's not that I think basing a filesystem on a database is a great idea. For one thing, it's a pretty good bet that performance is going to suck because of all the extra DB-related overhead. Administration might become more of a PITA too. I'm just trying to explain that the idea of a database-oriented filesystem has much broader implications than the trivial crap (much of which is relevant to neither filesystems nor databases) that people seem to be focusing on in this thread so far.
Slashdot - News for Herds. Stuff that Splatters.
I keep hearing people say, "don't take our file extentions away; they're ok!". Well, let me tell you, moving content type into meta data does not take away the functionality that file extentions provide.
There is only one problem with file extentions; file extentions are not reliable. There is no requirement for a file to have an extention. If there were, extentions would actually be meta-data seperate from file name; they'd just be stored right beside file name. Implementing meta-data based content type does not mean that content type must stop appearing as part of the name of a file. It does not mean that content type will stop being a delimiting factor between naming of files. When you create two files, one "document.txt" and one "document.xml" you are creating two files called document; one is a text file and the other is an xml file. The only difference between those two file names was extention. What would make it so impossible to have two files called document that are set appart from a user interface perspective by file type? Yes, I know that pretty much every program would need to use a different API for accessing files, and yes I know that your directory type inodes would need new formats (but who cares, it's a new file system any way).
Storing content type (extentions do not count as storing content type, they only do sometimes, if we're lucky as they are not reliable) does not mean that it'll be hard to interopt with non content-type systems. For instance, Linux and Windows both interact with HTTP just fine. HTTP uses content-type headers to define type, and totally ignores the extention; the servers and clients must translate between the content type header and extention if they want. There's no reason that other applications can't do the same for interoperability between systems.
People just don't want to do the work to change pretty much every application for Unix that exists. That's a very valid arguement. Adding a new file system that supports meta-data would change the UNIX API for files, and would probably break POSIX or something. We use old standards like FTP and EXT2 which don't have much of a concept of meta-data. It would be a major piece of work (and really a new OS - although it'd be very easy to port unix apps to it) to fully implement extended meta-data. But it's damned cool to do it! If we did it right, we'd listen to Hans Reiser's paper at http://www.namesys.com/whitepaper.html and make a damned cool awesome file system. And why not? (appart from all of the work)
Think about it. Searching for content across an enterprise will be used primarily by middle managers and others of higher order ambiguous executive titleature. It will be used in the never-ending quest to micromanage and meddle with formerly successful projects. The downfall of this system will result from one word:
Synergy
The PHB types just can't resist that word, and when the going gets tough, the feeble minded will grope the enterprise file system by searching for this single word. With either the volume of searches or volume of hits, the system will melt-down and freeze as only Microsoft crap can!
-- Len
"real" databases have auditing features that can be used to track your every move. If Monopolysoft is turning their filesystem into a database, it is highly likely that such spyware capabilities will come along for the ride.
Do you really trust Microsoft (or any cabal of amoral profit whores) to look out for your interests?
A Pirate and a Puritan look the same on a balance sheet.
I thought Microsoft had ceased all development in favor of fixing the security holes.
On that note, I wonder if this file system will be any more secure than their previous attempts.
~.Evanrude
The new technology will cause practically all Microsoft products to be rewritten to take advantage of it.
I don't get it, why rewrite the applications if they are running on a new filesystem? fopen/fclose/etc they should all work the same on any filesystem. Heck, with linux I have multiple file systems on different partitions. I've copied entire partitions from one filesystem to another with no problems. Am I missing something here?
Outdoor digital photography, mostly in New Engl
Let me guess... XPFS?
Naturally, it wouldn't be compatible with Windows XP.
Remember "Bring 'em on"? *sigh
I don't think it's imperative for the administrator to have the power by default to completely break an OS. Sure it's good to have that option and power, but I like the OS not letting me do something really stupid because I'm tired or distracted. For every "denied" message you get as an admin, chances are you can give yourself access to do this.
An example is SYSVOL on Win 2000 - by default, you should not have to modify the Active Directory by hand or see its file structure, you should use the tools that are built-in. But if you really want to, take ownership of the directory and give yourself rights - now you can do any sort of damage you wish.
Please subscribe to see the more insightful version of th
Yes, other platforms have had this forever, but they were fringe, or as is the case of MacOS, still pretty minority.
And yes, Microsoft's implementation will undoubtably suck in some way, or is being done for the wrong reasons, or whatever.
None of those things matter. This is still good news anyway. Why? Because it will finally get modern filesystems into the mainstream.
And then the Unix guys will have to get it. Just like the KDE and GNOME projects, they won't do it because metadata makes sense (even though it does), but because they'll want to keep up with the Gateses. They can't stand MS having a bullet point that they don't, or another "Linux isn't ready for the mainstream" article.
Result: a few years from now, my Linux fileserver will have metadata. About fscking time!!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I think that the best way to do this would be to implement a file(1) into the system that other applications (file manager, desktop GUI, applications) could use to determine what a file is.
How much have you used file? According to it, about 10% of the Project Gutenberg texts (virtually plain text, with some HTML) are spreadsheets for some Apple program. I run it over a directory full of program source, executables and half compiled stuff, and get told I have DBase files, a PDP-11 overlay, Spectrum TAP data and X11 SNF font data, none of which is right. It calls the Ada code variants of ASCII text or ASCII English text. file's a great tool for manual use, but it has way too high a error ratio to be used automatically.
If MS shit in a box (which they pretty much did with win ME) CNET would still love it.
But only if they marked it guaranteed.
Exactly, metadata is what we're missing from our files. So each file has to implement its own way of storing new info about itself. They specifically mention XML in the article, which would make it extremely easy for each application to add its own attributes to its files, and for other applications to figure out what those attributes mean and how to use them.
I think being able to search email and files in the same command will be a welcome addition to Windows. Perhaps this can even eliminate some duplicate storage, as email attachments don't need to be detached to become a normal file on the disk.
Please subscribe to see the more insightful version of th
Expect to see DRM at the filesystem level as well.
And plenty of breakage, at least in the first several iterations of the versions of Windows using the filesystem format.
Unfortunately, of course, upgrading is unlikely to be optional.
The Future of Human Evolution: Autonomy
Which is why 'innovation' is more of a buzzword than a verb. Innovation solves a problem. In the Linux community, if enough people want a new FS, one will get built.
MS 'innovates', and then tells people its what they wanted (or that it improves, no questions asked, what it replaces). Thats not innovation, and the only motivations in those scenarios are: make morey money, planned obselecense, etc.
As for copying, EVERYONE COPIES. EVERY SINGLE GODDAMNED BRILLIANT MUSICIAN/ENGINEER/WHATEVER COULD ONLY INNOVATE BY COPYING PREVIOUS IDEAS. The notion of 'copying' something and improving it is not innovation is A COMPLETE FALSEHOOD. The question is, do the costs (and I'm talking social costs such as training or usability, time costs, not only $$ costs) of deploying a new technology outwiegh the cost of staying with the current one? Thats a question MS will never ask, nor will its consumers care. A scary situation - at least in the Linux world, needs will be met. Innovation for innovations sake is a complete waste of time, unless you're in an economy, where, unfortauntely, its a requirement to keep things going.
"Old man yells at systemd"
Did you actually read the article by any chance? It specifically mentions IFS and how it's relevant to this discussion.
Nearly two years ago, Oracle introduced something called Internet File System, which works with its database server to make storage and retrieval of data
Please subscribe to see the more insightful version of th
I personally can't wait for this (and for *nix's to follow of course). Here's a good example of what we were dreaming of doing with it:
Each mp3 on a file server has a file entry of course. The schema is then extended to add attributes such as "last played" "last played by user" "times played" etc.. then when the song was accessed by the web server, it would increment the times-played, change the last-played timestamp, etc..
sure you can accomplish all this in other ways (like meta files, dedicated databases, etc), but it would be more convenient this way, especially since files could be moved around without having to worry about creating an indexing scheme to sync the file location and the external database.
Other tricks that could be done would be to better organize the music selection, so that browsing by artist would SELECT ALL WHERE ARTIST = foo, even if they were in albums, compilations, etc. You could also store things like images, videos, lyrics, etc.. in with the song, too. Personal playlists could be built with a simple schema as well.
_______
2B1ASK1
:)
hawk
Relational DB for filesystems? If this is based on SQL Server, that is exactly what it will be. Will that help or hurt?
It seems to me that the traditional concept of a filesystem is that of a hierarchical database manager more similar to LDAP than SQL-92.
Will this have serious performance tradeoffs?
LedgerSMB: Open source Accounting/ERP
Windows NT 4.0 Terminal Server with Citrix MetaFrame is ALMOST identical to WinFrame 2.0 Gold that never shipped. Microsoft wrote a BIG check to license Citrix's codebase for NT 4 and NT 5.
If you honestly feel that Web Browsers and RDBMS systems are chosen for the same reasons... well you probably feel that MySQL is a RDBMS...
Alex
Another unverified, just my personal experience, YMMV tip is removing any files from your desktop. If you store files there, especially large ones, it will slow windows down. Even a large number of shortcuts can have an effect.
Yes, I know you are not supposed to store things on the desktop, but windows makes it far too easy to do so. Plus it has the advantage that once you have downloaded a file, you can see it immediately without having to navigate to the right directory.
why were you using FAT32 at all when NTFS is available?
I can tell you why I do it: shared file space for linux that I can write to as well as read from. Maybe it has improved, but the last time I read anything about it, a year or so ago, rw on ntfs was not as easy or stable as fat32. Has that changed?
First Slashdotter: MS is coming out with a new "revolutionary" file system! *bash* *bash* *bash*
All Slashdotters: Burn it! Burn it!
Rational observer: Well, how do you know it's so bad?
First Slashdotter: Well, it's from...MS!
All Slashdotters: Yeah! Yeah! Burn it! Yeah!
It's 10 PM. Do you know if you're un-American?
Comment removed based on user account deletion
In Windows 2000, you can already mount drives to an empty directory you create instead of, or in addition to, your normal drive letter. This allows to have more drives than 28, but can also be used to create logical filenames for many drives. If you need details about how to do this, let me know, I can probably find a link. But it's in Disk Management of course.
Please subscribe to see the more insightful version of th
It's not perfect, but it relies on magic(5), the hints file with signatures of the various types of files. If you have a small magic(5) file you get stuff wrong, and some signatures need to be made "deeper" or smarter tests built in so that otherwise similar files can be told apart.
I can see where it would be advisable to have your file manager or desktop GUI be able to update the magic(5) file by being told that one or more of the files are different and that better signatures need to be generated -- eg, find out what's the same about files a and b but isn't the same as c and d.
Anything is naturally going to have some glitches, and some choices will always need to have an arbitrary definition since the definition of what they are may vary depending on interpretation.
I just think that the overwhelming majority of files *will* be machine-typable based on contents with hints and that adding a lot of extra data to the filesystem will cripple its speed in the long run.
January 2002: CEO Steve Ballmer says, "We want to evolve our storage system."
What ever happened to the market deciding what features are in demand?!
I'm a 2000 man.
Source to what?
[o]_O
Wow, I'm sure you convinced a lot of people that I'm wrong. My post was from my experiance. How the hell would you know what my personal experiance was?
autopr0n is like, down and stuff.
If you look around, people are saying this is just going to make your file system into one big database. I'll leave the reliability of M$ databases alone to answer your pressing concern. If you read the intro to this article again in the right light you have it:
ts planned that the new filesystem will make searches easier, faster, and more reliable.
That's searches of YOUR file system, but not always YOUR searches. By the new XP EULA M$ has delcared the right to check your entire file system for copy-right violating material and remove it. They also reserve, as do all the slave masterts, the right to terminate your license at anytime they decide you are non complient. So put it together. You copy N-Stink, they turn you off. Nice eh? You don't put it past the company that records every song you listen to and how many times with their media player, do you? Pay per play is on the way.
If there exists files on your computer not needed to run the computer itself which you can not modifiy, copy or remove, but someone else can, Then they are root and you are not.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
I have two fat32 drives in my current PC, both of which only have a few hundred megs free. My C: drive in particular once filled up completely (0k free).
I have never had any noticable dataloss on either of those drives, in 3 years of operation. And win98 use to only have any uptime of a day or so before I got my new mobo.
In contrast, ext2 loses data like a sive if you don't shut down properly (like if x locks or whatever)
autopr0n is like, down and stuff.
Be had the best FS
:)
Whoops, sorry, SGI was there first with XFS. BeFS was actually modelled after XFS. These days Linux has XFS with all its kick-arse features too, including extended attributes, and options that never were in BeFS (quotas, real-time I/O, NFS, etc) . The only thing missing is the automatic attribute indexing, but that could very well be implemented in userspace if you use the node monitoring feature of XFS. Come to think of it, that would be a damn cool project to do
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
For every "denied" message you get as an admin, chances are you can give yourself access to do this.
An administrator (sysadmin, root, whatever) should never be denied access to anything ever, no way, no how, zip, zilch, nada.
Without full access to the machine, and every resource on it, it is impossible to properly administrate it.
"Permission Denied" shouldn't even exist for the administrator account.
When you look at an 'assembly' in .NET, you'll see it's not 1 file, but a name for a lot of files, with different data. Still, it's seen as 1 unit. The same with f.e. Worddocuments with embedded COM objects. As a unit, the .doc file, it's known to the user, but in fact it's a store with a lot of blocks of data, which could be seen as a 'file'.
:)
_that's_ the reason for this change (which was expected for some time though). The filesystem as it is today is too limited to cope with units with blocks because you can't see a subset of blocks from, say, 3 files, as 1 'file'. You can when you have a 'filesystem' (a store is a better name) that doesn't use 'files' but just stores the atomic units and the relations between these atomic units. A 'query' utilizing these relations will then result in what we know today as a 'file'.
It's nice to see that the store will be based on SQLServer's OFS. MS has 2 database teams: SQLServer and Exchange. For long it was thought that the Exchange serverstore database would be the DB format of choice for this OS store. It's more optimized for using with large amounts of small blobs. But it seems SQLServer can do the job
Never underestimate the relief of true separation of Religion and State.
The fact is that you really can't search for images with current technology, you can only search on the text that describes them. (Which once again brings GREP, etc. back into the picture).
Layout sucks, it's overrated, and is just a pain in the ass, (on the web, at least) for those of use who like to keep our monitors set to 1600x1200.
--Mike--
I wonder how many R&D projects get canned in MS. Probably a whole lot. And considering building a new FS is nowhere near innovative. Are you suggesting that MS thought up the idea of this new type of FS? Puhleeze.
My beliefs do not require that you agree with them.
I just think that the overwhelming majority of files *will* be machine-typable based on contents with hints
99% will. That last 1% will cause a lot of pain and stress everytime it comes up, though. I have a file of OCR'ed pages from a book, and 3 of them come up as MSX game cartridge dumps. A visual inspection reveals no reason, it just happened to match the magic. So what happens when I'm working through the directory? I hit page 178, and for no apparent reason, my system tries to load it into game emulator. There's no way to permentaly tell it that this is a text file, so either I have to mess with the hints or handle it manually everytime. Ugh, ugh, ugh.
What about the flip side, all the files that file doesn't match? Like the gcov files I was complaining about. They all have sane file extensions - in any system where metadata was included, the creator could easily have set it to "GCOV Basic Block data". It's a lot harder to get file to guess it, though, especially as it probably is an ad-hoc file format with no magic numbers.
Furthermore, if the metadata's wrong, I can usually blame on a program and possibly get a fix. I can also easily change the metadata on that file to fix it. file is not an exact tool, and cannot be an exact tool, and there's no way to fix it for one file, and it's a pain to add a file type.
adding a lot of extra data to the filesystem will cripple its speed in the long run.
The Be filesystem was known for being fast, and it had all this data. How's one string going to change things? There may be metadata that shouldn't go in the filesystem, but file type has a long history of being in the filesystem, and working nicely.
Magicbits is a hack that gets perpetuated for one reason
Magic bits shouldn't be the only way to identify a file - they indeed have all the problems you mention. However, the reason why magic bits exist and will and should continue to exist, is because stuff doesn't always work right. Gnutella is filled with mislabeled files, and I've downloaded a file, just to come back and realized I've actually downloaded a 404 page and saved it as a zip. It's cheap and easy to put a few bytes at the start of your format and provide a way for a tool to fairly reliabaly tell whether it's really a TIFF file or not. It's good for verifying a file, not so much identifing a file.
Google doesn't 'grep' its entire data repository of text each time you do a search. It uses an indexed database, much like what Microsoft is proposing to use (only Google's is designed to scale much much higher). So sure, you can store everything in ASCII, but then you still need some sort of indexing to make searching of a reasonable speed when you get up to large (hundreds of gigabytes) filesystems. And if you're going to do that anyway, you might as well extend it and allow yourself to store textual metadata about binary files instead of limiting yourself to 100% ASCII files.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
This is only the public unveiling of a technology that has been under development for some time, probably as part of the Cairo project. Our first glimpse of it was actually in the first Halloween Memo of 1998, whence it was referred to as 'Storage+'.
Eric's summary from the relevant section:
"I'm told by a former Microserf that the references to "Storage+" here and in the executive summary are much more significant than they seem. MS's plan for the next few years is to move to an integrated file/data/storage system based upon Exchange, completely replacing the current FAT and NTFS file systems. They are absolutely planning on one monolithic structure, called "megaserver", as their next strategic infrastructure. The lock-in effect of this would be immense if they succeed. "
It is depressing that Linux is copying some (or all) of the stupid things in Windows.
However(!), in my personal experience, NTFS has been absolutely TERRIBLE! I have run both workstations and servers with NTFS and disk access is always abismally slow, permissions never work as expected, and corruption is a recurring problem. This is on a number of different machines with different hardware and different versions of Windows.
Does anyone have an explaination for this? Were there serious problems that have recently been addressed?
Sticking feathers up your butt does not make you a chicken - Tyler Durden
those are good points, and would definetely give a user leverage in finding their data. I purport that it's windows own doing, window's file browser window is pathetic, and the find utility plain sucks.
So would this be useful in unix? Sure it would. But is it necessary? Watching any seasoned unix d00d walk a filesystem is a treat. Using find, grep, awk, perl, etc gives a tremendous advantage over the windows side. I'm just not sure that this type of filesystem is necessary.
Not if your database server has its own datastore functionality built in -- and many do. You know how Oracle can work with raw partitions directly? Think 'bout that kind of functionality, just done by MS.
:-)
I'd rather not. I barely tolerate vfat only because I dual boot for games.
Humorless sig goes here.
But root can redefine it so it can be deleted, right? That's a nice feature. Doesn't change the point.
There are things that are not only not permitted by an administrator on an NT machine, but also CANNOT BE CHANGED by the administrator on an NT machine.
Therefore, they are not administrators. Period.
'Nothing is as simple as it seems at first Or as hopeless as it seems in the middle Or as finished as it seems in the end.'
Quoted by the slashdot quote generator at the bottom of the Next Windows to Have New File System article.
Perfect.
but obviously MS and many others disagree
Fine. Then don't call it an "administrator" account. Call it the "Person who is sort of in charge of the machine, but we'll decide if we think they know what they are doing" account.
You go right ahead and get full rights and break it for no reason.
Break a Windows install? That happens by itself. It certainly doesn't need an administrator account.
As for Linux, I've typed a wrong command or two as root before. It happens. But not having 100% control of a system is a security hole that a cruise ship could be driven through sideways.
I just hope they make it into the 80ties and get rid of the blackslash, and replace it by the normal slash, like god supposed it to be :o)
... mountpoints are directories where another file resides, so you're cdrom is example not D:\... but /cdrom/... , what are the advantages? Simple, if you plug in a new hardware the drive positions do not move, or break installed applications like on windows. You can add a new partition to you're first hard disk, and don't watch the letters of all partitions of the second hard disc move. the name /cdrom is self speaking, but E:\ is not. and of course you can have more than 26 devices :o)
And mount points! Will they finally get rid of the these stupid drive letters, and get mountpoints instead? I mean what can be so difficult with that, unixes managed to do a lot better since 30 years.
(For the windoze only people
--
Karma 50, and all I got was this lousy T-Shirt.
As others have indicated, the ^H indicates a CTRL+H character (ASCII 8) which is a backspace/delete on old VT100 and I believe ANSI terminals.
When someone writes something, follows it with some ^H^H stuff, then writes a different word, it's like saying:
Potential Sucker...er...ummm...I mean...uhh...Customer.
Actually, Windows DLLs do have versioning. It's just that not all apps check versions. They just load SOMETHING.DLL and assume it's the right version.
One post in here got me thinking. Maybe part of this is intended to be a shot at Oracle. If their file system is really a database, and they provide standard database functionality (including SQL, etc) with the filesystem layered over it, then they can argue more reasonably that which was so obviously false with IE -- that it is an integral part of the operating system, and cannot be removed.
When the OS ships with the database build in and "free", Oracle is a much less attractive choice. No, it won't destroy Oracle due to many of the other advantages it has (cross-platform, arguably better features/performance), but it could certainly give it a good smacking around.
Thoughts?
-Puk
User right clicks on OFS.dll.
Selects properties.
Properties box comes up.
User clicks on Company Name.
Stac Exlectronics comes up...then after a brief flurry of ethernet packets over User's cable modem..a series of ^H's is sent and now reads:
Microsoft Corp. (A.D.) {A.D. = After DoJ).
Of course that would never happen.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Sure it's good to have that option and power, but I like the OS not letting me do something really stupid because I'm tired or distracted.
... but really: when i use an admin account i pay attention to what i do, i read critical commands before hitting return, and i have 'mv' and the like aliased to 'mv -i' (chicken mode). One can argue that different levels of administrative power make sense, (not on private PCs) but the highest instance should be able to do anything, including breaking the system.
Don't drink and root
For every "denied" message you get as an admin, chances are you can give yourself access to do this.
While that might be the case i don't consider it the OSes job to pamper the sysadmin. If Windows changes file-attributes on a whim it is actively getting in the way. I prefer to do what i need to do without first overcoming hurdles thrown in my way by a tool that is supposed to help (not hinder) me. Asking for confirmation is ok, but flat out denying access is not helpful.
Note that you can change file attributes in Linux/Unix too, so the admin first has to change em back before anyone (including him) can remove them. But this is not applied automatically. This uppity behaviour of Windows is actually what i hate most about it. It's still me that owns the computer, not the other way round.
--
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Oh, Jar-jar. Everybody hates you but me! *smooch*
You are in a maze of twisty little passages, all alike.
1. It is vital that it be easy for a program to get *all* the data about a file (the metadata and data) into a single block of bytes. This is because a huge amount of software is concerned with transferring of file's contents from point a to b and needing to force the data through unknown communication mechanisms, most of which involve imbedding the file into another file. Most people here think MicroSoft is going to put us back to the 1960's where "pip" was a huge and complex and bug-loaded mess, and abandon the Unix "cp" which is tiny.
2. It is also vital that *every single piece of data* be accessable by a single string name passed to the *SAME* call (ie "open"), followed by some seeking and reading (the less the better), and the data is retrievable. Both Unix and Windows fall down badly here (see Plan9 and the Linux /proc for examples of solutions) but it is strongly believed that MicroSoft's programmers are too stupid to do this correctly.
One reason a lot of people say "imbed the data in the file" is to solve #1. However this makes #2 difficult. It is also impossible for file formats that don't have the ability to store an arbitrary-sized comment. But conversly (unlike what I think MicroSoft wants to do) we should not *disallow* putting the data in the file, this would instead be a last-stage fallback. It is also the only way to store this data on legacy file systems so it is still readable by older systems.
My proposal requires changing the file system so that very small files are FAST and every file is a directory. I believe ReiserFS has both of these requirements.
1. Pieces of metadata is accessed by opening and reading or writing "filename/metadataname". Attempts to write badly-formatted metadata may fail on close() and leave the data unchanged.
2. Every single piece of information about the file except it's name is metadata. This includes the date, owner, group, permission bits, ACL. (obviously you need the correct permission to change any metadata, and some hacks are needed to prevent "give this file to somebody else" security risks).
3. A "block" of data including all metadata is accessed by opening and reading or writing "filename/". Seeks are not allowed. The resulting data would be somewhat like tar. This should return the entire contents of directory trees as one block.
4. Add some calls to libc to use this to atomically copy or move any name to any other, preserving metadata and recursively copying subdirectories (like cp -a).
5. Provide a library that constructs missing metadata by examining the file itself for comments, examining the filename, etc. Programs may call this library instead of reading the metadata directly.
If you start an X session as a normal user, then open a term and su root, then try to run a gui app the X server won't let you.
So another way in which linux is like Windows.
graspee
Me: What happen?
Windows XP: Somebody set up us the upgrade.
Me: What !
Me: New operating system turn on !
Me: It's you !!
Windows NG (next generation): How are you gentlemen !!
Windows NG: All your file are belong to OFS.
Windows NG: You are on the way to .NET and DRM.
Me: What you say !!
Windows NG: Your mp3 have no chance to survive make your time
Windows NG: Have a nice day.
Me: Take off every boot disk
Me: Load Ranish Partition Manager
Me: Move Mandrake 12.0 install DVD
Me: For great justice
--
SQL Server 6.5 was able to store the database on a RAW disk. In SQL Server 7.0 Microsoft made the stupid decision to quit supporting RAW disks and now the database has to reside on top of NTFS. Sounds like they're going to have to redo everything they threw away in the name of "progress."
I have a website. It's about Macs.
For a end-user OS, the metadata mechanism should not have "some glitches".
Name one widely used OS that has a perfect, glitch free metadata system? Windows has its problems, MacOS has its, Unix largely relies on extensions or ignores file metadata altogether.
Furthermore, I dont think any system will be perfect -- I can open EPS files in at least 3 or 4 applications, and there's nothing in the file that says I should open it with any of them, since I may go from Illustrator to Photoshop to Corel Draw or vice-versa with a file created by any of them. Only I can choose which file will open them yet I guarantee that the goal of most metadata systems is primarily to open the right program when you double-click on the file.
Don't throw the baby out with the bath water.
A "file" expresses a fundamentally useful idea: a clear demarcation of data that lives independent of the host filesystem. Once you start tieing and interweaving data tightly with the host filesystem, how do you export it without a significant, altering transformation?
That is, when someone "just emailed you the project", what did you get? How much of the filesystem did or didn't come along with it? Have we openned the door for Version Hell? Also, can the data be compressed without having to know that it is?
Let's just be careful to clearly define what we want and how we get it.
A "file" lets us abstract the data from the filesystem. It is then trivial for that data to live on Ext2, Ext3, FAT16, NTFS, Juliet, in a zip, in a tar, as an email attachment, or in a pipe to an arbitrary process.
With a "common data storage", it sounds like what is really wanted is for each "object" to emit a standard, common interface. Once everything has that interface, we can wrap a database system around it to transform the data in lots of unique, interesting ways. Is there something implicit about this new abstraction that it has to live in the filesystem instead of on it (Is-A versus Has-A inheritence)? Does it require that we to throw out other, existing, useful abstractions ("files") to get it?
It sounds like an equivalent solution is to encapsulate each file in a platform independent, self-describing data structure. Then, impose the database query system on top of that. That both maintains the separation between file and filesystem provides all the features of the "common data storage".
Cairo (NT's sucessor) was once announced to have this feature, with automatic indexing in the file system and so on. I don't remember the time it was supposed to be relased. Was it 1997?
>Eventually Linux might have this feature ... yet
>more evidence that *bsd is years ahead of linux
No, its evidence that you don't know what you're talking about. Linux has supported immutable and append-only flags since the 1.1 series of kernels, way back around 1994.
Matt
There's more to metadata than just file types. What about comments, icons, ratings, and other stuff that nobody's thought of yet? In a GUI shell, directories need stuff like icon positions, default view mode, default sort order, etc.
I dunno if you've got access to an OS/2 machine around somewhere, but if you do, look at the properties of a directory or a file sometime, to get some idea of how many small, but useful, pieces of info get attached. At work, I recently switched from OS/2 to Linux, and the limitations of a Windows-styled GUI (Nautilus) are pretty jarring. Having that stuff was sooooo nice... I miss it. :(
Ok, let's take a best-case example, such as PNG or IFF with their chunky and extensible structure, so that anything you might want to add to the file, can easily be done. You wanna rewrite part of the file whenever someone moves or changes its icon? Ew... I do a "window clean up" and suddenly all the dates and times on all my files are the same? Ick.
Portability. *sigh* I guess that's the problem: if Gnome is to be portable, then it will always have some pretty severe limitations. This is one of the things that makes the whole Gnome/KDE battle so pathetic: they will always suck as much as Windows.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
How old is this?
/. several times.
Some of those articles go back to 98, and yes it's been on
Microsoft are going to use an SQL-based filesystem, and only offer hierarchical (old skool) file access though an NTFS abstraction layer. Essentially, there will be a copy of MS-SQL server bundled with the OS, which will always be faster than any SQL database running on top of the OS, which is really going to piss off Oracle.
This feature was originally planned of Blackcombe, but it was decided that another iteration was needed before then. Hence Longhorn.
And I didn't even bother to read the article.
"I think he was truly surprised at how little I cared about how big a market the Mac had" - Linus on Jobs
I fear this. I will have to support it eventually. From personal experience they still have not figured out what a 'stable' fs is yet. Sql6.5 was an example about how it took them 5 OS patch levels and 5 Software patch levels just to become 95% stable. (I dare you to try and restore 10 DB and not have a problem with memory fragmentation)
BTW IBM have had this since the S/36. Its called a filessystem for the data and a database for the databse type needs.
A large portion of 'data' in the filesystem is wothless to search on. Take a image file for instance. The only 'real' database worthy information is about a image. So why not just have a DB with the info bits of relavant files included. Maybe text files should be put in the db verbatum, but raw data (images, video, audio,etc) just don't make sense to include in a all-for-one-and-one-for-all approach.
Pretty soon we will have google-type-bots on or pc's finding lost info for us. ala locate/updatedb.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
I remember going through SQL Server 7 training at MS and them telling us it doesn't support raw disks anymore. I always thought it was a dumb thing to do. *shrug*
I have a website. It's about Macs.
Recent media reports about Micros~1 new filesy~1 have revealed that in order to make search~1 docume~1 easier, all words will be trunca~1 to eight charac~1. In order to mainta~1 backwa~1 compat~1 the indexing will begin at 1 and go throug~1 to 9. Micros~1 is accept~1 submis~2 on which words will make the Micros~1 contro~1 list of availa~1 words. Micros~1 CEO Steve Ballmer admits that in some cases plurals and at worst, whole words will not make the list.
"For instance, there have been so many submis~1 for the monopo~ and anti-t~ domains that we have not been able to includ~1 the words 'anti-trust' and 'monopoly' in Micros~1 Englis~1 (tm). We do not howeve~1 see that this will limit our abilit~1 to commun~2 effect~2", said a smirki~1 Ballmer.
"She's a West Texas girl, just like me" - G.W Bush Iraqis
I've been using NTFS for years at work, and with all the blue screens, crashes and power failures I've put many hundreds of machines through, I've never lost more than an occasional file to corruption.
Sigh. I should have known better. Hell, I DO know better, and that's even worse.
Looks like I'll just have to keep a FAT32 partition for ME, and not even bother to mount it under XP, just to keep it safe in the future.
John
Isn't it great that we can all visit Slashdot and not be exposed to any nasty opinions with which we might disagree?!
Don't spend much time on a shell prompt?
^H = Ctrl-H, the Delete key on your keyboard.
-- I wanna decide who lives and who dies - Crow T. Robot, MST3K
Yeah, it's different inside the box. But are they going to immediately make SMB incompatible with all their other products as well? Are they going to stop large corps installing this OS because they cannot afford to switch every desktop and/or server overnight just because MS have a cool idea?
.NET to see how they intend exporting these filesystems around a network? Why export filesystems when they really want to export data sources?
OTOH, it will make building dual-boot machines even more fun, and you can be damn sure it will implement some form of copyright control.
Perhaps look at
Xix.
"Everything is adjustable, provided you have the right tools"
This move is designed to avoid the Settlement terms.
By making the filesystem a database, and conveniently sourcing the database from a third party, they won't have to release any specs for interoperability etc. since their filesystem will essentially be supplied by a third party who is not required to disclose anything under the terms of the MS settlement.
I gots ta ding a ding dang my dang a long ling long
I think you meant to say that the Japanese language become obsolete when computers were introduced. Seriously, after the typewriter they had plenty of warning...
The only time I've LOST files off of any FAT16/32/NTFS drive was back in the FAT16 days. I made the youthful mistake of getting DOS 6.2 from a BBS (at 14.4 those days... thank goodness.. well, compared to a 2400). I then proceeded to install a DoubleSpace drive. Then, I got tired of it, removed the driver from config.sys, and deleted the DoubleSpace file. Well, after random files started disappearing from our computer, I called Gateway 2000 and their tech informed me that that MS had something going on "behind the scenes" that would seriously screw up if you deleted the compressed drive file. Well, this was my father's computer (with all of his law firm's documents on it), so I had to spend the ENTIRE night copying all of his files to 250 1.2MB 5.25" floppies. Then I had to fdisk, format, and re-install DOS/Win. Needless to say, I have NEVER messed with drive compression since.
Sorry for the long post. Crazy flashback. It was one of those moments where you are infinitely wiser immediately afterward. Now that I look back on it, the only reason I'm so comfortable with computers is that I broke them so often. Eventually there was no one else to call, no more books to read, and no INTERNET (well, shell dialup doesn't count). The fear of a 260 lb. 6 foot 5 father who's law firm is on the line is an amazing motivator.
Then this is where the bashing happens. Microsoft obviously took no great pains to keep critical data out of harms' way. Not only did I lose the registry, but I lost hal.dll and ntoskrnl.exe in the power failure, too. There was absolutely nothing left to boot from. I was just fortunate that none of the newer files (read: my not-yet-backed-up files) seemed to have been affected.
John
Parent-post:Windows 2000 automatically set the permissions to the file in such a way that I could no longer modify the file on that computer (trying to add comments, or even allowing administrator to read/write to the file).
That's effectively chmod, which can be a checkbox. It's not an access control mechanism.
Of course its an access control mechanism. It allows the network or system administrator to control access to the files. What else would you call it?
What it is not is a DRM technology because it still leaves the administrator in control. DRM cannot do that because the administrator is (presumably) has not bought rights to copy the media.
LedgerSMB: Open source Accounting/ERP
Incorrect. There are files that cannot be changed by the administrator, unless the administrator goes and resets the permissions on the file. (Same with registry entries; HKLM\SAM, for example).
This has been pointed out to you in other posts, but you're still not getting it.
OFS, wasn't that the os prior to FastFilesystem on amiga? (FFS)
:)
they should have skipped to the next letter. PFS... uh no ProFileSystem on amiga again, is there a QFS yet?
Anyways, With the current stuff microsoft is hiding in it's OS/filesystem I wouldn't be surprised to see a LOT of spyware/logware in an obscure filesystem like this, and this time, *REALLY* hidden, at least for a year or two the time some people code low-level disk tools.
The scary thing is I don't see the need to upgrade past NTFS5 until I get 13+TB raids (ntfs's limit). I am currently at 1.2 on my datacenter so it's probably still going to be a few years (I hope). I wonder what tactic they'll use to shove it down to reluctant people like me into using it. Up to now I didn't need to use XP, and I'm happy with win2k. I evaluated XP for 3 days and I've returned it (didn't activate it). I hope the next generation won't suck as much, and if it does, I hope I'll be able to keep win2k for that one has well.
--- Metamoderating abusive downgraders since my 300th post.
The point is there should be no such concept as "permission denied" for an administrator. Either they are administrators or they are not. The very notion that there is some process/account/structure that must bestow permission to an administrator, even if it is their own account, redefines the role of administrator to something else.
The details are really irrelevant. The point is that the administrator should have permission to do anything, without any redundant "grant permission to myself" process involved. Anything less is in itself a security problem because there exists the possibility that the administrator can be "locked out" of a system.
If I "chmod 000" a file, then theoretically even root should not have the ability to delete it, right? It's world-non-readable/world-non-writable. Yet, root can rm -f the file with no problem, error messages, warnings, dialog boxes, requests for permission, meetings, resolutions, upgrades or "Are you sure?" questions. Why?
BECAUSE THEY ARE ROOT AND DO NOT REQUIRE PERMISSION.
Sure it will: man xauth.
Name one widely used OS that has a perfect, glitch free metadata system? Windows has its problems, MacOS has its, Unix largely relies on extensions or ignores file metadata altogether.
But their glitches are predicatable and usually fixable on a file by file level. If a file is named foo.txt, Windows and Unix will handle it as a text file. I can change the filename and fix that. A Mac has a certain metadata that can be changed if it's wrong.
But in a file(1) system, there are unpredicatable and unfixable glitches. I have 200 text files in a directory, and 3 don't work. Why - I don't know, they just happen to match some magic. There's no way to fix it, short of messing with file(1)'s internal data, or changing the problematic file; the first is difficult and fruitless (as you can't, in general, tell a text file from another sort of file), and the second is unacceptable.
Another unverified, just my personal experience, YMMV tip is only keeping static installs of programs on your C drive (partition) including the icons on your desktop.
:)
I change the MyDocuments, Internet browser cache and downloading directories (ie. for stuff like Kazaa) folders to another partition (I call mine SCRATCH) and keep all temporary stuff there. After I know I want to keep the data, I move it to yet another partition that stores 'permanent' data.
This technique minimizes fragmentation on your C drive (and on the 'data partition' to a lesser extent). Fragmentation slows loading times of software, because the OS can't load the program in large contiguous chunks if it is fragmented all over the place.
Short of reinstalling Windows every 12 months, this is what I do to keep my programs loading quickly in Windows. It would be nice if this was done automatically though.
----- rL
I agree that the admin should have the right to do anything, I think my point was that if Windows is trying to stop me from something, chances are I shouldn't be doing it. There's nothing I really wanted to do in Windows and haven't been able to figure out how to get the rights to do it. Files, registry keys, AD nodes, just take ownership and it's yours for the wrecking. I think it's just a matter of background, it sounds like *nix admins love having the built-in ability to kill the system without any safety checks, while I might not have the same opinion. To each his own, right?
Please subscribe to see the more insightful version of th
Twaddle. IBM screwed up OS/2 by insisting that it support the PC AT with the derranged 286 memory scheme.
Microsoft hired much more of the VMS team than Dave Cutler. Even if they did just hire 'one guy' it was the guy in charge.
The first release WNT internals were so close to those of VMS that VMS system programers such as myself pretty much knew most of the O/S when it was released. That would be quite a coincidence if it was OS/2 underneath.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
In tex text files, special characters might get encoded in various ways, e.g. "a to specify ä.
Searching for the German word "während" will fail if the ä character is encoded differently.
Wait, you mean people actualy RUN error checking on FAT32 partitions?
/too/ many applications open, but hey, that is to be expected. :) Everything was perfectly usable at full speed though. Rather nifty, I did not at first realize I had no Hard Drive space left, LOL!
... issue ... when your Hard Drive is compleatly full though, LOL!)
I have yet to see Scandisk actualy ever FIND anything on a crashed Win9x machine, therefore after the first few years I just started bypassing it.
Oh, and I have had my NTFS paritition filled to 100% (as in 0 bytes remaining) and Win2K ran just fine. Bit of a slowdown if I had
(shutting down Windows can be an
Need help treating your acne? Come here!
I know- I just wanted to point out that under linux there are some things were it will tell you as root that you don't have permission to do...
graspee
.. because we no longer can trust what we see on the desktop. you would be able to discard the true identity of a file from the user. like renaming 'evil_virus.exe' to 'naked.gif', giving it the standard icon of a .gif file, but keeping the meta-information ("windows exectuable"). No user will check the meta information before clicking on this file.
Oh look a Windows troll. Perhaps you should get yourself a sense of humour and stop assuming that I use Linux as well.
Of course, XP will always have the registry open, and who knows what else it might have fired up at 2:00 AM on a Saturday morning. Perhaps it was time for its scheduled system recovery backup thing. I really can't keep track of all the randomness Microsoft introduces in each version of Windows.
I agree that it shouldn't have been trashed by a mere power failure. (Of course I'd agree!) But I can say that I have never seen a drive so lost after a crash that didn't end up being physically damaged. This damage was quite extensive. (Chkdsk found lots to clean up, but I think it may have caused even more damage than I originally had.)
So, now I just don't know. Was my crash really a FAT32 fault? Or is there a hidden hardware demon lurking in the sectors, scraping cylinders from my drive?
John
Re: "ACLs are one thing that should be prevalent on new filesystem designs."
Before Microsoft puts too much time into a new file system, I'd like to see it make full use of the existing NTFS one -- especially the ACLs. I'd like the OS and program files to be in an area that cannot be written to by anybody on the outside, or even by myself unless I'm logged on with a privileged account -- to eliminate any possibility of upgrades/viruses and other stuff getting installed over the net or from e-mails, etc.
John Gorentz
If you're really hosed, use a disk imaging system like norton ghost to backup, then restore, your hard disk.
The files will all be defragged, because norton reads one file at a time into the image, then writes back the restore one file at a time.
Presto, instant, fast defrag.
hanzie.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
Right. First of all, we were talking about administration, which hopefully assumes a higher level of literacy. Secondly, remember when users would telnet into Unix to use all their applications? I bet all of them were very very computer literate. The "Windows users are dumb, Unix people are smart" is such a tired tired cliche, shame on you for retrudging it yet again.
Please subscribe to see the more insightful version of th
But I thought you just said that it was a nice feature that in various flavors of Unix, you could set a file to be immutable so that even root couldn't delete/change it:
Of course, it's possible to take that flag off if you boot into single-user mode. That's even more restrictive than in NT, where you don't have to boot into any special mode, you just have to give yourself permission. So either Unix root is even less powerful than NT Administrator, or they're both all-powerful. I don't care which you pick, but you have to be consistent--you can't say that Unix root is all-powerful, but NT Admin is weak.