Microsoft geeft videopresentatie over WinFS

Microsoft heeft op TechNet een videopresentatie neergezet over het nieuwe bestandssysteem WinFS. Deze presentatie wordt gegeven door Quentin Clark, Director of Program Management bij Microsoft, en zijn taak is ervoor te zorgen dat WinFS en bijbehorende technologieën op de juiste manier in Windows Longhorn verwerkt worden. Zoals inmiddels bekend mag wezen, is WinFS één van de drie pilaren waarop Windows Longhorn gebouwd wordt. De andere twee zijn Indigo (communicatiesubsysteem) en Avalon (grafische engine). Voordat er begonnen is met de ontwikkeling van het nieuwe bestandssysteem is er door de ontwikkelaars onderzocht wat de trends zijn op het gebied van dataopslag en informatieverwerking. Zo kwamen ze er achter dat gegevens tegenwoordig op totaal andere manieren verwerkt en gebruikt worden dan enkele jaren geleden. Ook merkten ze dat het terugvinden van data steeds moeilijker is geworden.

Op basis van de gegevens die de ontwikkelaars gevonden hadden, zijn ze bezig gegaan met de ontwikkeling van een nieuw datamodel. Eén van de belangrijkste en opvallendste punten uit het model is het feit dat het draait om relaties die gelegd worden tussen de verschillende gegevensbronnen. Zo zou het mogelijk moeten gaan worden om op een eenvoudige manier alle documenten van één bepaalde auteur terug te vinden. Ook moet het dan mogelijk zijn om gegevens die aan die documenten gekoppeld zijn, bijvoorbeeld een afspraak voor een vergadering over een discussienota, terug te vinden. Op deze pagina is een schema te vinden met een aantal voorbeeldrelaties en bijbehorende eigenschappen. Een probleem is dan echter dat het leggen van die relaties een taak is die moeilijk aan software over gelaten kan worden. Dit is gedeeltelijk op te vangen door gebruik te maken bepaalde regels die aan de hand van input een bepaalde actie uitvoeren. Hier is door Microsoft onder andere aandacht aan besteed in de vorm van speciale schema's en operations die uitgevoerd kunnen worden.

De basis voor WinFS is het vertrouwde NTFS. Hiervoor is gekozen om compatible te blijven met oudere applicaties die gebruik maken van specifieke NTFS-API's. Bovenop deze basis staat de Relational Engine. Hiervoor is dezelfde engine gebruikt als in MSSQL. Deze wordt gebruikt om met behulp van SQL relaties te leggen tussen de gegevens in het bestandssysteem. Hier bovenop staan twee onderdelen die samen de basis vormen om te kunnen werken met WinFS. Aan de ene kant is dit het Datamodel, met de daarbij behorende onderdelen, en aan de andere kant staan twee technologieën die gebruikt worden om relaties te leggen tussen NTFS-bestanden en WinFS-items en om bestanden te manipuleren. Het Datamodel bevat op zijn beurt drie onderdelen, namelijk Items, Relationships en Extensions. De Items zijn de kleinste deeltjes waarmee gewerkt kan worden in WinFS, bijvoorbeeld een contactpersoon of een document. Via de Relationships worden de relaties tussen de items vastgelegd. Hierbij wordt weer gebruikgemaakt van het onderdeel Operations uit het andere blok. Tenslotte zijn er de Extensions. Dit zijn zelfgedefinieerde Items.

Bovenop deze twee onderdelen staan opnieuw twee andere onderdelen, dit zijn Synchronisation en InfoAgent. Synchronisation is een onderdeel van WinFS waarmee het mogelijk is om wijzigingen in gegevens op een eenvoudige manier samen te voegen en te synchroniseren. Als bijvoorbeeld twee personen de adresgegevens van dezelfde contactpersoon hebben gewijzigd, kunnen deze wijzigingen tegelijkertijd worden doorgevoerd. Als gegevens dan conflicteren hangt het van de gebruikte itemschema's af, wat er gebeurt met de conflicterende data. InfoAgent kan gebruikt worden om bepaalde acties uit te voeren op basis van bepaalde input of wijzigingen in data. Dit is te vergelijken met berichtregels in een e-mailprogramma. Naast deze twee onderdelen staat het onderdeel Schema's. Dit is onder te verdelen in twee onderdelen, namelijk Windows-schema's en Developersschema's. De Windows-schema's zijn de schema's die standaard aanwezig zijn en waarin is vastgelegd hoe er met bepaalde gegevens, contacten en documenten, omgegaan moet worden. Developersschema's kunnen worden gebruikt worden om eigen schema's te definiëren voor bijvoorbeeld zelfgeschreven bestandstypen, bijvoorbeeld financiële of medische gegevens.

Hier bovenop staat tenslotte het belangrijkste onderdeel voor de ontwikkelaar: de API's. Dit zijn er drie, namelijk Objects, XML en T-SQL. De Objects stellen de ontwikkelaar in staat om in programmacode vast te leggen hoe bepaalde gegevens uit een Item gehaald moeten worden. Dit programmeerwerk werkt op dezelfde wijze als programmeren in .NET. XML wordt gebruikt om gegevens op te halen uit het bestandssysteem. Deze XML kan vervolgens getransformeerd worden om gebruikt te worden in andere applicaties of om data weer te geven. T-SQL kan gebruikt worden om via SQL - complexe - queries te doen op gegevens in WinFS om relaties te leggen tussen gegevens. Hierbij wordt gebruik gemaakt van de Relational Engine. Dit is echter alleen bruikbaar om te lezen. Het bijwerken of verwijderen van gegevens moet op een andere manier plaatsvinden.

Reacties (65)

[Dennis]

Hierboven is het allemaal heel mooi beschreven door de nieuwsposter! Ik heb deze week al de video hiervan gekeken maar moet toch wel zeggen dat ik onder de indruk ben van het idee achter WINFS.

Wat overduidelijk de doelstelling van dit nieuwe "FileSystem" is, is om de harde grens tussen logische en fysieke opslag weg te nemen. Dat is ook de trend die Microsoft al heel lang geleden aankondigde. Men wil de grens tussen mens en machine verkleinen.

Bestanden zijn straks geen bestanden meer, maar een object. Net als een e-mailtje. Dat is wel een mooi voorbeeld om even uit te lichten. Laten we even Outlook nemen als voorbeeld. Outlook slaat e-mailberichten op in pst-bestanden (mits lokaal gebruikt). Nou is het heel vervelend om e-mail berichten te zoeken in zo'n pst-bestand als je Outlook niet hebt. Niet handig dus.
Met WinFS zal een e-mailtje als e-mail object worden opgeslagen. Op die manier kun je dus direct al je mailtjes bekijken zonder ze eigenlijk te moeten openen met een specifieke applicatie. Tel daarbij de mogelijkheden van queries en xml op en je hebt uniforme data-uitwisseling tussen alle programma's.

Het is een klein beetje vergelijkbaar met Active Directory. Daarin is ook alles een object. Een gebruiker is geen gebruiker meer, maar een gebruikersobject. Een gebruikersobject kent bepaalde eigenschappen. Net als een e-mailtje straks een ontvangstdatum heeft, een onderwerp, etc.

Andere dingen die je dus kunt verwachten zijn contacten. Die kun je straks gewoon bekijken zonder een speciaal programma. Mensen die de bèta's van Longhorn testen weten waar ik het over heb, omdat contacten eenzelfde soort map is geworden als Mijn Documenten.

Al met al een mooie ontwikkeling.

[Verwijderd]

En Active Directory is weer gebaseerd op het X.500 directory protocol, wat weer voor een groot gedeelte groot is gemaakt door Novell's NDS en eDirectory, welke weer geschoeid waren op de Bindery .. ga zo maar door

[vso]

volgens mij was het gebaseerd op LDAP Lightweight Directory Access Protocol

M.a.w veel lezen en weinig schrijven. Dit is wel een intressant punt. de kracht van dit systeem zit hem dus in het feit dat je een data base cree-ert (onder linux & BSD updatedb) waarbij je met een command (bv locate) zeer snel het juiste bestand kan vinden.

LDAP werkt ook eigenlijk met het zelfde principe je schrijft een database met alle objecten en hun eigenschappen. en dat is eigelijk de basis van je structuur of Domain zoals in windows 2k en 2k3 is gebeurd. 1 centrale database voor de basis informatie van je systeem.


hier en daar lees ik dat je meerdere lagen model vertraging / hack gevoelig zou zijn. Elk software produkt kan inefficent zijn en bugs bevatten dat geef ik toe. ik denk dat mits goed afgestemd er een hoop snelheid in zou kunnen zitten.

[Loesje]

X.500 was er het eerst. Daaruitvoortgekomen zijn eDir van Novell, AD en als laatste het Opensource initiafief LDAP. Ze zouden compatible aan elkaar moeten zijn, omdat ze allemaal aan de X.500 voldoen. Maar AD doet dat uiteraard niet. . .

[WhistlerNL]

wat ik me afvraag is of we nog iets van snelheidsverbetering of verslechtering gaan merken.

als ik ff heel simpel nadenk: er word allerlei extra meuk om ntfs heen gebouwd, waardoor het niet echt logisch klinkt dat het sneller gaat werken imo

weet iemand hier wat over?

[Verwijderd]

Je gaat er vanuit dat je de database én het filesystem moet benaderen voor alle bewerkingen, maar dat is natuurlijk lang niet altijd nodig.

Neem bijvoorbeeld zoeken op bestandsnaam. Om op een NTFS-partitie te zoeken op bestanden die beginnen met een 'a' kost behoorlijk wat tijd. Als je in een database zoekt op records die beginnen met een 'a', ben je binnen no-time klaar. Een kwestie van slim indexeren.

Vergelijk maar eens 'find' en 'locate' onder linux, dan weet je waar ik het over heb.

[Superstudent]

Ja dat vrees ik dus ook. Al die koppelingen met SQL e.d. zullen het echt niet versnellen. Een extra laag tussen het filesystem en het OS kan gewoon niet bervorderend zijn. Ok, er zullen wel interessante opties bij komen, vooral in combinatie met internet applicaties...maar ojee de beveiliging woei, hoe gaat MS ervoor zorgen dat hier geen exploits in zitten! En elke keer als ze zoiets "revolutionairs" verzinnen, vraag ik me af waarom maken ze het huidige systeem niet eerst minder kwetsbaar? Het kan haast niet missen dat het weer een boel nieuwe potentiele beveiligingslekken gaat opleveren....
Ik ben benieuwd

[rtgo]

Even op de eerste post: mime types als totale vervanging van extenties zie ik bepaald niet zitten. Extenties zorgen nog enigzins ervoor dat niet elke file een uitvoerbaar (lees: virus) is. Ik zie het al voor me: je krijgt een mailtje met viezexxxsletjes.jpg en dan wordt hij opeens uitgevoerd omdat het mimetype zegt dat je hem moet uitvoeren bij het openen.
Je ziet nu al dat er veel virusproblemen zijn door mensen die niet letten op extenties. Hoe zou dat zijn als er geen extenties meer zouden zijn?

Anyway, op zich wel leuk dat MS verder gaat met het onwikkelen van haar filesystems maar ik vraag me af of de gewonen consument van de nieuwe mogelijkheden gebruik wil maken. Betere indexering is schattig maar voor de thuisgebruiker zijn er toch belangrijkere dingen zoals snelheid en rigiditeit. Je FS moet een normale crash zonder veel problemen kunnen overleven (NTFS was nogal een vooruitgang op FAT32) maar het moet ook snel zijn. Voor dat laatste kan die vernieuwde indexering helpen, maar het indexeren zelf zal veel tijd kosten. Ik ben benieuwd maar ik zal zeker niet een van de voorlopers zijn bij het gebruik van WinFS; ik wacht liever even af.

Gaat hierbij niet onnodig veel hardeschijfruimte verloren aan deze db? Uit de nieuwspost valt te lezen dat er per bestand heel wat koppelingen gelegd worden, en op een 120gb hdd passen heel erg veel word- en excel-docs. Nem aan dat je dan zeker een paar 100mb aan database kwijt bent, toch een verspilling van je hardecshijfruimte (afhankelijk van de exacte grootte van de db in percentages van je hdd-ruimte vraag ik me af of dat wel opweegt tegen de voordelen.... (zeker als het niet uit valt te schakelen; Microsoft heeft soms van die neigingen...)).

zelfs al is het een GB dan valt het nog in het niet t.o.v. het 'creatieve' tellen van de harddisk fabrikanten. Ik zou er niet zo mee zitten. De prijs van 1GB schijfruimte ligt (in de aanschaf) nu al ver onder de euro dus dat overleef ik wel.

[YaPP]

Even op de eerste post: mime types als totale vervanging van extenties zie ik bepaald niet zitten. Extenties zorgen nog enigzins ervoor dat niet elke file een uitvoerbaar (lees: virus) is.

Het probleem met extenties is, dat de virusmaker invloed heeft op hetgeen wat jouw pc uitvoerd. Nogmaals, een naam mag nooit bepalen wat een systeem met een file doet.

In plaats van een extentie hoor je naar de inhoud van een bestand te kijken, met andere woorden, het werkelijke mime-type. Dit doet bijvoorbeeld de Konqueror file manager in de KDE desktop, door naar de inhoud van een bestand te kijken. (die ziet bijvoorbeeld al dat een halve edonkey download een mpeg film is, super handig) De apache webserver gebruikt ook een mime-magic module voor dit soort zaken.

Ik zie het al voor me: je krijgt een mailtje met viezexxxsletjes.jpg en dan wordt hij opeens uitgevoerd omdat het mimetype zegt dat je hem moet uitvoeren bij het openen.

Onder unix achtige systemen bijvoorbeeld, maakt de extentie niet uit, maar geld er maar 1 ding: de executable-bit. En deze zul je zelf moeten aanzetten als je een attachment opslaat op de schijf.

Een programma is dus pas een programma als jij dat expliciet zelf aangeeft.. imho een goede aanpak, want dit houd gevaarlijke attachments tegen. (en installers zetten uiteraard wel een executable bit aan, dus 'jan met de pet' hoeft er niet naar om te kijken)

Ik hoop dat WinFS ook op een degelijke manier dit soort restricties oplegd, anders wordt het een grote petrischaal voor virussen en exploits. Microsoft maakt een erg groot en complex systeem, wat veel risico met zich meebrengt.

[packman]

Voor die executable flag zouden ze het gewoon zoals in *NIX achtigen moeten doen... Executable is dan gewoon een attribute van de file. Werkt heel mooi...

[Flatline]

Laat ik me nou nog herinneren uit het NT4 MCSE traject: NTFS, een filesystem zonder beperkingen waar geen fragmentatie bij optreed.....

En winfs wordt hierop gebaseerd; bij symantec etc zal men wel een feestje vieren. Een zeker toekomst voor hun utilities!

[Mr.Aargh]

Het wordt er niet op gebaseerd, de basis is juist 'anders', de 'presentatie' naar de buitenwereld is NTFS (dit mbt tot de API's en software die er gebruik van maken).

[Shin_Alu]

In tegendeel, de basis is juist hetzelfde.
Zoals hierboven beschreven is het NTFS met erbovenop een extra laag.

[voodooless]

Precies. Eerst roepen ze dat ze een compleet nieuw filesysteem gaan maken... wat blijkt, ze nemen NTFS en SQL server, en gooien het op een hoopje..

[-=bas=-]

Beter goed gejat dan slecht zelf verzonnen!

Laagjes ergens bovenop bouwen, daar is Microsoft echt een kei in. Niet dat het de functionaliteit en stabiliteit ten goede komt,.

[k7of9]

aangezien NTFS en SQL Server beiden van MS zijn jatten ze dus van zichzelf...

En denk je dat andere OS'en ook niet uit lagen bestaan?

En WinFS biedt juist heel veel functionaliteit mogelijkheden, iets wat je zou kunnen weten als je de moeite zou nemen om je erin te verdiepen.

[Mizitras]

Oftwel, men vinde uit, het MicroSoft-wiel. Net zoals x-jaar geleden, alleen nog eens overgedaan nu.

Iemand volgende:
Men moet geen oude uit de sloot halen.

[boner]

Ik hoop dat er ook iets zoals de file-fork van de apple in komt te zitten. Dus niet een applicatie selecteren op extensie (.xls dus excel of .wks=1-2-3) maar iets meer expliciets.

[jvo]

Wat is precies het voordeel daarvan?
Dat komt toch eigenlijk letterlijk op hetzelfde neer?
(edit: Ok, is wat kort door bocht, maar leg uit.)

[BezurK]

Nou, ik zal de kwestie eens uitleggen aan de hand van een simpel voorbeeld:
Stel, je bent webdeveloper, en je maakt graag je web-pagina's in Dreamweaver. Normaal gesproken opent IE (of enig andere browser) alles wat .html is. Met andere woorden: er kan maar 1 programma geassocieerd worden met een bepaalde extensie. Maar je wilt bijvoorbeeld dat je alle html normaal gesproken geopend wordt door IE, behàlve de pagina's die je zelf gemaakt hebt, die moeten geopend worden met Dreamweaver. Dit kan normaal gesproken niet. Nu zou het dus handig zijn als elke file voorzien zou kunnen worden van een soort meta-tag (of file-description of whatever) waarin staat wat het exàct voor file is. Daarin zou dus kunnen staan "Internet Explorer HTML" of "Macromedia Dreamweaver HTML" of wat dan ook.

Dit is natuurlijk slechts een voorbeeld maar ik denk dat ik het hiermee aardig duidelijk maak

[Cyphax]

Dat is ongeveer hetzelfde als nu het bestand met een andere (nieuwe, zelfgemaakte?) extensie opslaan dus? Immers, stel dat ik het Dreamweaver HTML bestand wil openen in IE?
Dan heb je dezelfde situatie als nu... ongeveer dan.
Het maakt het geheel niet makkelijker als je 't mij vraagt. Misschien kun je een voordeel noemen van je voorbeeld?

De beste oplossing die MS bedacht heeft voor dit probleem is wat mij betreft nog steeds "open with" submenu'tje en daarin de programma's waarmee je dat bestand al geopend hebt (in dit geval dus de keuze tussen Dreamweaver en IE).

Verder ben ik benieuwd naar de prestaties die dit FS gaat leveren. Ik zie weer lagen en API's voor backwards compatibility...

"relaties die gelegd worden tussen de verschillende gegevensbronnen" klinkt heel leuk natuurlijk, queries op je bestandssysteem loslaten... we zullen het eens zien over een paar jaar

[Verwijderd]

Voordeel: je weet nu nooit of er niet een ander bedrijf is dat dezelfde extensie kiest voor een bestandstype. Neem bijvoorbeeld de welbekende .nfo. Windows opent die normaal gesproken met System Information of zoiets, en kan natuurlijk niets met je .nfo's van je "backups". Als je nu de .nfo zou uitbreiden met een extra tag waarin beschreven wordt welke applicatie verantwoordelijk is voor het bestand (door middel van een MIME type, developer, directe link met applicatie, ...), worden de "Windows" .nfo's geopend in dat System Information en je backup .nfo's in UltraEdit (bv).
Dat red je nooit met "eigen" extensies, omdat je nooit zeker kan weten dat niemand anders die extensie gebruikt.

[freaky]

phooha wat een kwestie... rechts klik openen met....

wat wou je dan? file openen. please select which app you would like to use, ie, dreamweaver, mozilla, word, excel, frontpage, fireworks, freesite lekker handig als je dat iedere keer moet kiezen.

HTML is HTML. Hoe wou je in godsnaam het verschil bepalen tussen iets wat je nog moet bewerken en iets wat al klaar is? .wiphtml (work in progress html) en .html ofzo? dan kun je daarna gaan renamen, daar word je ook niet veel vrolijker van. Mag in ieder geval toch hopen dat nadat je klaar bent met dreamweaver het toch ooit in een browser geopend gaat worden.

en tja MIME types... linux gebruikt het iig al jaren extenties zijn iig onbetrouwbaar.

[YaPP]

Ik hoop dat er ook iets zoals de file-fork van de apple in komt te zitten. Dus niet een applicatie selecteren op extensie (.xls dus excel of .wks=1-2-3) maar iets meer expliciets.

Wat is precies het voordeel daarvan?
Dat komt toch eigenlijk letterlijk op hetzelfde neer?

Stel je bent een virus, genaamt virus.exe. Er is geen bescherming die zegt dat virus.exe niet mag worden uitgevoerd, en grapje.exe wel. Windows ziet .exe, en zal het willen uitvoeren. (een fout die bijvoorbeeld veel outlook express virussen misbruiken)

Beveiligings/technisch gezien, mag een naam nooit bepalen wat er met een bestand gedaan wordt. Of iets executable is laat je nu dus aan de virusmaker over, en niet aan de 'wijsheid' van je systeem zelf.

[KnoppenSpook]

Ja een soort Meta tag, met de MIME-type.
Dit systeem gaat ook best wel op Meta tags rusten volgens mij.

[Luxx]

dat heeft toch eigenlijk niets met het filesystem te maken. Natuurlijk is het een raar idee dat de extentie allen bepaald wat er met een bestand moet gebeuren. Maar uiteindelijk heeft het niet zo veel met het filesysteem te maken.

[Verwijderd]

Windows 2003 is al een stuk trager dan b.v. Samba.
Als ze straks ook nog eerst een MSSQL server moeten raadplegen(Ook niet een van de snelsten) dan word het volgens mij wel een heel erg trage omgeving.

[Verwijderd]

Alvast een paar MS-Dos aliases:

alias dir=SELECT * FROM %1;
alias delete=DELETE %1 FROM %CD;

[bstard]

En daarnaast kan je samba op XFS laten gieren.. ik verbaas me nog regelmatig over hoe snel dat FS is (de linux port van SGI). Zolang M$ daar niet in de buurt komt.. ach, ze moeten wat om voor dat Longhorn pakketje weer 100/200 eurii te vragen. Staat leuk zo´n blaat verhaal.

[Verwijderd]

Volgens mij is de Ferrari van nu ook gebouwd rondom de eerste auto van rond 1900. En toch is die een stuk sneller geworden....

Nou da's onzin. Ook onder de motorkap is er heel wat veranderd hoor !

Ik kan me zo ergeren aan al dat gezeik over wel of niet sneller, terwijl er nog niets echt werkend te zien is.

Tjah, als het technisch al onmogelijk is om een hogere doorvoersnelheid te behalen met dit concept, lijkt dat me toch geen voorbarige conclusie.

Maak je geen zorgen zou ik denken, tegen de tijd dat WinFS beschikbaar komt is het of van zichzelf al snel genoeg, of is de hardware zoveel sneller etc. geworden, dat ook dan WinFS snel genoeg is.

Blame it on the hardware .
Als de hardware sneller zou zijn schud ik ook in een jaartje een FS uit mn mouw wat 10x beter is. Maar vooral voor serveromgevingen lijkt het van belang dat het FS zo goed mogelijk presteert. Tweakers kan ook wel gaan upgraden, maar ze hopen juist met hun huidige hardware een zo goed mogelijke performance te halen.

En niet zeuren over iets wat in principe veel mogelijkheden heeft, maar afgekraakt wordt hier omdat Microsoft er mee komt.....

Hmm. Ik heb hier nog geen voorbeelden van MS bashing gezien hoor ...

[Verwijderd]

Het WinFS is gebaseerd op NTFS... Dus ook daar zal onder de motorkap heel wat veranderen naar ik mag aannemen, maar wat we pas zeker weten op het moment dat WinFS commercieel beschikbaar komt.
Technisch is het nu nog moeilijk te realiseren, omdat en de hard- en de software dit nu nog niet kunnen. En, is het niet altijd al een Blame it on the Hardware? Door betere hardware kunnen we MAC OS/X draaien, of Win XP of Linux/Gnome 2.0. Probeer dat allemaal maar eens op een 8086 met 16Kb intern geheugen.
En, dit noem jij geen MS bashing? MS komt met een goed idee, maar omdat het van MS is, zijn 9 van de 10 reacties hier negatief. Dit had onze held Linux Thorvald eens moeten deponeren, dan zou je de lovende reacties hier eens moeten lezen...

[Verwijderd]

Dit had onze held Linux Thorvald eens moeten deponeren, dan zou je de lovende reacties hier eens moeten lezen...

Zegt je het filesystem Reiser4 wat?
misschien moet je daar eens naar kijken....

oh ja..het werkt onder Gnu/Linux

[Verwijderd]

Klote M$ ! Linux rulezzz !

Zo, daar heb je je MS bashing

[Verwijderd]

De huidige filesystems zijn inflexibel en domweg achterhaald. Ik heb me ook bezig gehouden met het ontwikkelen van een object-FS....

Een probleem is dan echter dat het leggen van die relaties een taak is die moeilijk aan software over gelaten kan worden. Dit is gedeeltelijk op te vangen door gebruik te maken bepaalde regels die aan de hand van input een bepaalde actie uitvoeren. Hier is door Microsoft onder andere aandacht aan besteed in de vorm van speciale schema's en operations die uitgevoerd kunnen worden.

Dat heb ik ook gemerkt ja ! Hoe kun je in software relaties vastleggen, waarbij je in feite onbeperkte events en reacties kunt definieren ? Dan krijg je weer een of ander traag scripting taaltje, wat iig niet perfect is...

Je zou het kunnen doen met hooks, en een bepaalde driver/dll/applicatie de events/reacties af laten handelen. Maar dat word natuurlijk supertraag als je dit een beetje op grote schaalt wilt gaan uitvoeren....

wat ik me afvraag is of we nog iets van snelheidsverbetering of verslechtering gaan merken.

als ik ff heel simpel nadenk: er word allerlei extra meuk om ntfs heen gebouwd, waardoor het niet echt logisch klinkt dat het sneller gaat werken imo

weet iemand hier wat over?

Hahaha, de zwakkelingen ! Ze hebben het idd rond NTFS gebouwd, dus het kan praktisch alleen maar trager worden ! Zo nieuw is dit "FS" dus niet, het is gewoon een database op een bestaand filesystem. Het enige verschil is dat het systeem nu die database bevraagt ipv adhv filenames/windows register etc te werken.

[Verwijderd]

Ik vind het hele idee verdacht veel lijken op wat BFS al sinds begin 1990 kan. Ik heb een paar jaar terug nog ergens een compleet artikel gelezen waarin bijna exact staat wat Microsoft hier claimt zelf bedacht te hebben. Kwam erop neer dat directories eigenlijk niet nodig waren als je een snel en krachtig full text indexed FS zou hebben (zie http://www.betips.net/TrackerBase/ voor een goed voorbeeld). Wel een goede ontwikkeling als het MS lukt dit goed te implementeren, met de hoeveelheden data tegenwoordig wordt een flexibel en snel FS steeds meer een vereiste.

[Verwijderd]

Ik hoop dat je uit ook makkelijk "uit"-kunt zetten..