Dravelfaktor > tillåten nivå => kan inte hålla mig.
Det beror väl inte på filsystemet, utan snarare på det usla operativsystemet.
Nej. Eller, typ nej i alla fall.
OK att allokeringspolicier kanske kan hävdas ligga i operativsystemet snarare än filsystemet (om du nu definierar det sistnämnda bara som ett dataformat), men detta tar oss snabbt till kärnproblemet med NTFS; överkomplexitet. Låt oss nu ta en liten titt på detta med dina inlägg som guide så återkommer vi till detta påstående.
Komplexitet
NTFS designades på en tid då det var oklart vad som skulle behövas för ett klientoperativsystem (som NT marknadsfördes som då) och ett serveroperativsystem (som MS i hemlighet hoppades att det skulle bli). Detta ledde till en design med fokus på extrem flexibilitet, vilket först kan låta väldigt bra, men så är inte nödvändigtvis fallet.
Exempel på saker man inte visste var huruvida flera dataströmmar per fil skulle bli vida använt (jmf resuser i macos eller filer i VMS) så man lade in stöd för godtyckligt många strömmar med tanken att i efterhand kunna definiera stöd för kärn-forcerat dataformat (tänk resurser igen). Allt detta kodades i i filpather vilket bland annat lett till allvarliga säkerhetsproblem med IIS. Ingen vet riktigt hur många andra program som eventuellt kommer lida av samma problem.
En annan sak som diskuterades då och som fortfarande diskuteras är det här med accesslistor och MAC (i detta fallet är MAC=mandatory access control) Låt oss nu titta vidare på det här med rättigheter som du talar så varmt om;
Sorry, Pär: NTFS är det enda Microsoft har gjort ordentligt. Jag skulle faktiskt vilja se det som ett framtida alternativ i OSX-miljö. Många trevliga egenskaper som on-the-fly-lagning och säkerhet på filnivå (inte OS-nivå som UNIX). Om man flyttar data med UID 501 till en ny maskin med UID501 blir man automatiskt ägare av datat. NTFS behåller den faktiska ägaren intakt oavsett "UID".
Om vi bortser från det här med "NTFS är det enda Microsoft har gjort ordentligt" som ju så uppenbarligen är dravel i bästa fallet och billig propaganda nån tryckt ner i halsen på dig i värsta, och i stället fokuserar på sakfrågan, nämligen konsekvenserna av UID-baserad, eller snarare UNIX-modellen för, autenticering och accesslistor med globalt unika användare och samtidigt sneglar lite på det här med komplexitet så ska vi se vad det bär.
I ett UID-baserat accesssystem har man en typiskt liten namnrymd (16 eller 32 bitar) där varje subjekt har ett eget unikt id. i UNIX är detta kallat uid eller "user id". Skyddsmodellen i UNIX bygger på enkelhet (snarare än flexibilitet) och varje objekt har en ägare och en grupp. Därefter definieras rättigheter på filen i tre dimensioner (ofta, men inte alltid "läs", "skriv" och "exekvera" som dock alltid kallas read, write och execute respektive) för ägaren, gruppen och övriga. Detta system används också i OS-X.
Om man tar ett rått filsystem från en dator till en annan kan man därför inte behålla användarinformationen på något bra sätt. På grund av detta flyttar man ofta filer i andra format än i råa filsystem där TAR är ett sådant exempel. TAR sparar mer information om exempelvis användarnamn (snarare än ett numeriskt ID) och kan därför bättre packas upp på andra datorer. Även system som backup/restore är vanliga.
I praktiken innebär detta att om man kopierar filer från ett flyttat filsystem blir man själv ägare av de nya filerna. I vanliga fall är detta inte ett problem, men i vissa specialfall kan det bli knas.
Fördelen med detta system är just enkelheten. Den ter sig nämligen i två former;
Det är (förhållandevis) lätt för användare att förstå innebörden av ett visst skydd. Sålunda är det svårt att göra fel
Det är (förhållandevis) lätt att skriva program för detta. Via råttan-på-repet-principen innebär lätt i detta fall få buggar och annat elände
I NTFS använder man accesslistor med arv och hela baletten där en fil eller annat subjekt skyddas av vad vi kan tänka oss vara en lång lista per användare och/eller grupp. Där finns för varje möjlig operation (som är fler än de tre vi tidigare nämnde och som kan ändras med tiden) ett beslut om access som typiskt är "ja", "nej" eller "ärvt". För att modifiera detta tarvas en hel del pyssel. Nu till verkligheten;
Accesslistor är komplexa att använda. Även om MS ger dig ett rart grafiskt gränssnitt (och ett fint diplom) för att trixa med sånt här så är det lätt att göra fel.
Det är komplext att skriva program för detta. När man kommunicerar med Windows tarvas på många håll en s.k. LPSECURITY_ATTRIBUTES där man beskriver dessa rättigheter ett nytt objekt ska ha. Jag har hitintillsaldrigsett ett värde annat än NULL på detta. NULL betyder "öööh vet inte; ge mig rimliga standardvärden, bitte"
En accesslista är lite som en diskussion på 99mac. Om det vill sig illa ligger många irrelevanta inlägg i listan innan man kommer till det man är på jakt efter. Detta gör modellen långsam.
Nu till en kort praktisk övning för den som inte tror mig. Betänk att du är i situationen att du vill att en användare ska kunna köra ett program men inte kopiera (läsa) det. I UNIX löses detta med x-rättigheter men utan r-rättigheter. Detta går att åstadkomma i Windows också; se hur lång tid det tar att få rätt på.
Detta räcker naturligtvis inte för komplexiteten i NTFS utan man drog dessutom på sig saker som inplace-komprimering, kryptering och ett komplext system för stora/små bokstäver i filnamn. Det sista hör kanske (men jag är inte helt övertygad) hemma i ett filsystem, men ta en titt på valfri UNIX (såsom MacOS) och titta var man lägger saker som krypterade hemkataloger (det ligger GARAN-JÄVLA-TERAT INTE i filsystemet).
Vidare törs jag påstå att den överväldigande majoriteten av både Windows och Mac-OS-installationer används på platser där det inte finns ett behov av en komplex autenticeringsmodell. Även om man har många barn fruar och hundar att dela dator räcker uid-baserade system(1). Om vi dessutom lägger till prestandaförlusten i NTFS så är det nog rätt få som vill ha det, egentligen. Men, eftersom MS ger dig så många valmöjligheter eller vad de nu snackar om finns ju FAT32 som inte har stöd för NÅGON autenticering, journalisering eller filer större än 4GB. Med andra ord så är det antingen att använda trehjulingen eller flygplanet. Och betala för den du väljer snarare än den du behöver.
Vidare vad gäller filsystem och komplexitet kan jag varmt anbefalla den intresserade läsaren att ta en titt i "Practical File System Design with the Be File System" av Dominic Giampaolo som finns gratis att ladda ner. Även en titt i "Design and Implementation of the FreeBSD Operating System" är nyttig. Varför, kan man undra. Jo för att man vad gäller ett normalt filsystem kan beskriva det i en bok eller delar av en bok så att någon kan implementera det. Det gavs ut en bok i slutet av nittiotalet (har jag för mig) som beskriver NTFS. Det är en introduktionstext som inte tillnärmelsevis räcker för att implementera en filsystemsdriver.
Bortsett från implementationen i Linux (som i princip är den alla andra öppna system också använder) finns det i princip ingen dokumentation på NTFS och hur det _verkligen_ fungerar. Om filsystemet är helt kan du montera det i en del operativsystem och läsa filerna. Skulle filsystemet bli skadat (ja, även journalförande system kan skadas) står du där. Har för mig att sysinterals säljer ett system som typ kan rädda lätt skadade filsystem. Om du har tur.
Så nu tillbaks till de här med allokeringspolicier (som är det som avgör fragmenterings-benägenhet). Visst, de ligger kanske i operativsystemet och inte i filsystemet som sådant. Men, och det är ett stort men, ska du in och rota i NTFS rotar du i ett filsystem som är bland de mest komplexa används. Det är dessutom tyngt av en accessmodell som så gott som ingen använder. Vidare måste förändringar testas så det inte blir knas i filsystemet, för blir det knas finns i princip inga verktyg som kan fixa till det. Av olika skäl som vi naturligtvis bara kan spekulera i har vissa saker som auto-defragmentering inte hittat sin väg till NTFS och på senare år har MS aktat sig rätt noga för att själva rota i soppan.
1) Med reservation för mormoner och 16-bitar, då 16-bitar tar slut vid 65536 så det kanske inte räcker till både barn, fruar och hundar. På en dator.
