OS Windows — Souborové systémy

Na souborových systémech FAT lze adresář považovat za speciální typ souboru. Ovladač souborového systému předpokládá, že data takového souboru reprezentují seznam položek, jenž daná složka obsahuje. Obsah takového souboru je interpretován jako pole 32bajtových záznamů. Ve zjednodušené variantě souborového systému, která nedovoluje jména souborů delší než 12 znaků (8 znaků na jméno a 3 znaky na příponu), každý takový záznam odpovídá jednomu souboru či podadresáři. Pole záznamů není žádným způsobem seřazeno, což znemožňuje implementovat rychlejší algoritmy například na testování existence objektu. Ovladač vždy musí prozkoumat každý záznam. Strukturu jednoho záznamu ukazuje tabulka 5.

Krom své délky jsou jména souborů a složek (DIR_Name) omezena také co se týče přípustných znaků. Nemohou obsahovat libovolný z následujících znaků:
" * +. /: ; < = >? [ \ ] |

Dále nejsou povoleny žádné znaky, jejichž kód ASCII je menší než 0x20. Výjimku z tohoto pravidla tvoří znak s kódem 0x05, který zastupuje znak s kódem 0xE5, jenž, pokud jím jméno položky začíná, má speciální význam. Do jména též nejsou ukládána malá písmena abecedy, ovladač souborového systému je automaticky konvertuje na velká.

První znak může nabývat několika speciálních hodnot: * 0xE5 – příslušný záznam neobsahuje platné informace o žádné položce. Nastavení této hodnoty znamená smazání daného souboru či složky ze seznamu položek adresáře. Z tohoto důvodu se může při obnovování ztracených dat z diskového oddílu formátovaného některým ze souborových systémů FAT stát, že obnovovací utilita nedokáže zrekonstruovat první znak jejich jmen.

Položka DIR_Attr obsahuje bitovou masku, která určuje tzv. atributy souboru (adresáře). Může nabývat jedné či několika z následujících příznaků:

Každý adresář obsahuje minimálně dva platné záznamy. První záznam se jmenuje „.“ a odkazuje na svého rodiče (je tedy synonymem pro aktuální adresář). Druhý záznam se jmenuje „..“ a odkazuje do adresářového stromu o úroveň výš než první záznam. Díky těmto položkám je ovladač souborového systému přirozeně schopen zpracovat cesty, které obsahují reference na aktuální (.) či nadřazenou složku (..). Ovladač souborového systému tyto položky emuluje.

Výše popsaná struktura adresáře omezuje maximální délku jména položek na celkem 12 znaků. Microsoft se toto omezení rozhodl zrušit již u souborového systému FAT16, a to takovým způsobem, aby byla zachována zpětná kompatibilita s již existujícími ovladači a utilitami pro správu disků. Položka adresáře se nyní neskládá pouze z jednoho 32bajtového záznamu, který popisuje její vlastnosti, ale i z dalších druhů záznamů, které obsahují její jméno.

Tyto nové záznamy mají též délku 32 bajtů a jejich struktura je podobná struktuře obyčejných záznamů, jež se někdy označují jako záznamy s krátkým jménem. Strukturu nového záznamu ukazuje tabulka 6.

Každý záznam dlouhého jména obsahuje nejvýše třináct znaků názvu položky. Každý soubor nebo adresář může být popsán až dvaceti těmito záznamy a jedním záznamem krátkého jména, což omezuje maximální délku názvu na 260 znaků. Interní limit je nastaven na 255 znaků.

Dlouhé jméno položky je vždy zakončeno jedním nulovým znakem ve formátu Unicode. Případné další nepoužité znaky v záznamu jsou vyplněny bajty s hodnotou 0xFF.

Každý soubor nebo adresář je popsán souvislým blokem záznamů dlouhého jména ihned následovaným jedním záznamem krátkého jména. Záznamy dlouhého jména jsou v tomto bloku uloženy v opačném pořadí, než by každý očekával. Struktura obsahující poslední znaky dlouhého jména se nachází v bloku jako první, kdežto záznam s pořadovým číslem 1, jenž obsahuje prvních 13 znaků jména, leží až těsně před záznamem krátkého jména. Situaci ilustruje obrázek 3.

Kromě větší maximální délky přinesla dlouhá jména souborů i adresářů možnost používat znaky, které jsou v krátkých názvech zakázány. Konkrétně se jedná o:
+. ; = [ ]

V dlouhých názvech se také častěji používají mezery, které patří i mezi povolené znaky do krátkých jmen. Nelze je použít pouze na počátku a konci dlouhého názvu (jsou ovladačem souborového systému ignorovány).

NOTE:Protože i soubory a adresáře s dlouhým jménem jsou reprezentovány jedním záznamem krátkého jména, disponují vlastně dvěma názvy. Ovladač souborového systému implementuje algoritmus, který pro dané dlouhé jméno vytváří jedinečný krátký název, který pak umisťuje do záznamu krátkého jména. Mezi dlouhými a krátkými jmény tedy existuje mapování 1:1. Více o tomto algoritmu najdete v dokumentu [13].

NTFS umožňuje definovat pro každý soubor či adresář oprávnění, kterými k němu mohou disponovat uživatelé či skupiny uživatelů. Bezpečnostní model implementovaný v souborovém systému používá stejná primitiva jako zbytek operačního systému. Každý otevřený soubor je správcem objektů reprezentován jako entita typu File, a tak mu lze (stejně jako každému jinému objektu exekutivy) přiřadit popisovač zabezpečení (security descriptor), jenž specifikuje, kteří uživatelé a skupiny s ním mohou provádět jaké operace.

Na rozdíl od většiny ostatních druhů objektů exekutivy a stejně jako v případě klíče registru (reprezentovaného správcem objektů entitou typu Key ) popisovače zabezpečení souborů a adresářů jsou uloženy v interních datových strukturách souborového systému, odkud je jádro v případě potřeby načte do paměti.

I souborový systém NTFS reprezentuje každý soubor a adresář jedním nebo více speciálními záznamy. Podrobnější informace o jejich struktuře se dočtete později v tomto oddílu. Jak se píše v předchozím oddílu, tento koncept platí i pro souborové systémy FAT. NTFS navíc umožňuje, aby na skupinu záznamů obsahující informace o jednom souboru vedlo z adresářového stromu více odkazů. Jinak řečeno, adresářový strom může obsahovat více souborů, které jsou interně reprezentovány pouze jednou skupinou záznamů.

Soubory v adresářové struktuře lze v jistém smyslu chápat jako odkazy na jejich záznamy v interních datových strukturách souborového systému. Každý takový soubor lze pak označit za hard link. Tento termín se však většinou používá až v případě násobných odkazů na skupinu záznamů s informacemi o jednom souboru.

Tento druh odkazů se označuje jako hard (tvrdé), protože se nejedná o žádné jmenné aliasy. Dokud existuje alespoň jeden odkaz na záznam o určitém souboru, tento záznam není ze souborového systému odstraněn.

Windows API umožňují vytvořit hard link pomocí funkce CreateHardLink. Jelikož se v podstatě jedná o vytvoření speciálního druhu souboru-odkazu, neexistuje žádná speciální rutina určená pro jejich odstranění a k tomuto účelu se používá funkce určená pro mazání obyčejných souborů – DeleteFile.

Každý záznam (či skupina záznamů) o určitém souboru si pamatuje, kolik odkazů na něho vede z adresářového stromu. Volání CreateHardLink tento čítač zvýší o jedničku. Rutina DeleteFile jej o jedničku snižuje. Klesne-li počet odkazů na nulu, záznam (či skupina záznamů) je odstraněn z datových struktur souborového systému.

Vícenásobné odkazování na objekty souborového systému pomocí hard linků má dvě velká omezení. Není možné se odkazovat na adresáře a nelze vytvářet linky na soubory nacházející se na jiných diskových oddílech či dokonce na jiných počítačích. Druhé omezení plyne právě z toho, jak jsou hard linky implementovány – jako odkazy na záznamy v interních strukturách souborového systému.

Soft linky provádějí podobnou činnost jako hard linky – způsobují přesměrování operací v adresářovém stromě. Netrpí však jejich nevýhodami, které zmiňuje předchozí odstavec. Lze je směrovat jak na adresáře, tak na soubory, a neplatí pro ně omezení působnosti na jeden souborový systém.

Soft linky fungují obdobně jako symbolické odkazy v rámci jmenného prostoru správce objektů. Jedná se pouze o jmenné aliasy cílových souborů či adresářů. Kdykoliv ovladač souborového systému při zpracovávání cesty narazí na soft link, nahradí celou cestu, nebo její část daty uloženými v soft linku (záleží na tom, zda symbolický odkaz na svůj cíl odkazuje absolutní, nebo relativní cestou) a výslednou cestu začne zpracovávat od začátku.

Protože se jedná pouze o jmenné aliasy, soft linky nejsou fyzicky svázány s cílovým objektem. Ten o jejich existenci vůbec nic neví. Nedochází k počítání referencí jako u hard linků. Když je cílový objekt odstraněn, soft linky, které na něho vedou, nadále existují a adresa jejich cíle se stává neplatnou.

NTFS reprezentuje soft link speciálním typem souboru nebo prázdného adresáře, typ odkazu a cílového objektu se musí shodovat. Informace o cílovém objektu jsou uloženy ve speciálních metadatech, která jsou uložena společně s dalšími informacemi o objektu a označují se jako reparse point. Jejich přítomnost lze poznat přečtením atributů objektu, které obsahují příznak FILE_ATTRIBUTE_REPARSE_POINT.

Na rozdíl od hard linků, rozhraní Windows API nedisponuje žádnými speciálními funkcemi pro manipulaci se symbolickými odkazy v rámci souborového systému. Pokud aplikace (nebo ovladač) potřebuje s těmito objekty pracovat, musí komunikovat pomocí rutiny DeviceIoControl přímo s ovladačem souborového systému (ntfs.sys). Podporované komunikační kódy pro práci se soft linky ukazuje tabulka 7

Názvy komunikačních kódů nasvědčují tomu, že neslouží primárně k tvorbě soft linků, ale přímo k manipulaci s metadaty reparse point. Tato metadata totiž slouží nejen k implementaci jmenných aliasů, ale mohou být využita k libovolnému rozšíření možností souborového systému pomocí ovladačů-filtrů. Součást metadat tvoří identifikátor jejich typu (tag), jenž určuje, k jakému účelu reparse point slouží.

Pokud chce tedy aplikace rozhodnout, zda určitý soubor či adresář je ve skutečnosti soft linkem, musí nejen zjistit, zda jeho atributy obsahují příznak FILE_ATTRIBUTE_REPARSE_POINT, ale prozkoumat i identifikátor typu metadat.

Obvyklá představa stromové struktury systému souborů na disku je taková, že tento strom se skládá ze dvou typů objektů – adresářů a souborů. Adresáře nejsou určeny k ukládání dat, ale mohou obsahovat další adresáře a soubory, které slouží právě k uchovávání dat.

NTFS tento koncept rozšiřuje o něco dále. Soubor může obsahovat nejen jeden, primární, proud dat – ten, ke kterému aplikace získá přístup, když soubor otevře, ale libovolné množství datových proudů dalších, označovaných jako alternativní.

Alternativní datové proudy (Alternate Data Stream – ADS) se od proudu primárních dat odlišují tím, že mají jména. Pokud chce aplikace (či jiná entita) manipulovat s jejich obsahem, musí při získávání handle k souboru (nebo adresáři; pojmenované proudy lze přidávat i přímo na adresáře, čímž ruší koncept adresářů neobsahujících žádná obecná data), za jeho jméno uvést znak „:“ následovaný jménem proudu. Například jméno
C:\Temp\test.txt:test
označuje alternativní datový proud test na souboru test.txt v adresáři C:\Temp . Tento název je ekvivalentní zápisu
C:\Temp\test.txt:test:$DATA

Řetězec za posledním znakem dvojtečky „:“ určuje typ datového proudu. $DATA je název vyhrazený pro alternativní proudy obsahující obecná data. Jak se dozvíte v části věnované podrobnějšímu popisu interních struktur souborového systému, existuje více typů datových proudů.

Primární datový proud nemá žádné jméno a v duchu konvence určení alternativních datových proudů jej lze na výše uvedeném souboru test.txt identifikovat pomocí řetězce
C:\Temp\test.txt::$DATA

Databázové servery či utility pro práci s obrazy disků mohou vytvářet velké soubory, z nichž prakticky k uložení užitečných dat využijí pouze velmi malou část. Pokud pro svoji činnost používají obyčejné soubory, může docházet k zbytečnému plýtvání volným místem. Datové oblasti obyčejného souboru, které aplikace pouvažují za volné, také zabírají volné místo na diskovém oddílu.

Řídké soubory (sparse file) jsou určeny právě pro výše zmiňované aplikace. Program takovému souboru může definovat oblasti, které neobsahují užitečná data. Souborový systém takovým oblastem nepřidělí žádné volné místo a navenek se tváří, jako by byly vyplněny samými nulovými bajty.

Navenek se řídké soubory chovají plně transparentně a pokud je aplikace neumí rozeznat, tváří se pro ni jako obyčejné soubory. Odlišit je lze pomocí nastaveného příznaku FILE_ATTRIBUTE_SPARSE_FILE v atributech. Jednotlivé souborové operace se chovají následovně:

Ani pro práci s řídkými soubory neexistují speciální funkce Windows API a je nutné použít rutinu DeviceIoControl pro přímou komunikaci s ovladačem souborového systému. Dostupné jsou následující zprávy:

Magnetické pevné disky, které se v době psaní této knihy stále ještě hojně používají, disponují dobrými rychlostmi čtení a zápisu sekvenčních dat. Problémy jim však působí náhodný přístup. Tato vlastnost je dána jejich fyzickou architekturou, kterou vidíte schematicky znázorněnou na obrázku 4.

Pevný disk tvoří několik nad sebou rotujících kotoučů – ploten. Jedna soustředná kružnice na jedné plotně se nazývá stopa a skládá se z množství co do kapacity stejně velkých bloků – sektorů. V dnešní době drtivá většina pevných disků pracuje se sektory, které pojmou 512 bajtů dat. Jiné druhy médií však mohou mít nastavenou velikost sektoru na odlišné hodnoty. Například u optických médií můžete narazit na 2 KB (2048 bajtů).

Systém stop nacházejících se v plotnách nad sebou se označuje jako cylindr. Mezi plotnami se nachází hlavy, které zajišťují operace čtení a zápisu dat.

Znalost fyzické struktury disku má význam pouze pro BIOS a pro nízkoúrovňové ovladače. Dnešní disky však již podporují tzv. způsob přístupu LBA (Logical Block Addressing). Chce-li operační systém na určité místo například zapsat 10 sektorů, nemusí zadávat počáteční sektor určením cylindru, hlavy a sektoru ve stopě (CHS – cylinder-head-sector address), ale pouze zadáním jeho čísla. Samotný disk totiž navenek předstírá, že funguje jako pole sektorů a uvnitř si jednotlivé bloky mapuje na CHS adresy.

Ukázku mapování logického prostoru na jednotlivé sektory fyzické struktury vidíte na obrázku 5.

Firmware pevného disku po sobě jdoucí sektory mapuje na adresy CHS tak, aby jejich sekvenčním čtením nebo zápisem docházelo k sekvenčnímu čtení nebo zápisu i na fyzické struktuře. Všimněte si také, že sektory se v případě adresy CHS číslují od jedničky.

Pro firmware tedy operace přečtení či zápisu sektoru znamená následující:

Operace nad sekvenčním blokem sektorů v sobě zahrnují teoreticky pouze jeden krok seek pro nastavení hlavy nad stopu počátečního sektoru. Při práci s následujícími sektory se již hlavy nachází na správném místě. Dochází tedy k ušetření přístupové doby, která se u magnetických pevných disků pohybuje v řádu jednotek milisekund. Z tohoto důvodu probíhají operace nad sekvenčními daty rychle. Náhodný přístup znamená v extrémním případě provádění operace seek při čtení nebo zápisu každého ze sektorů.

Vzhledem k výše popsaným vlastnostem magnetických pevných disků se vyplatí, aby i data jednotlivých souborů se nacházela pokud možno v jediné souvislé posloupnosti clusterů. Při povídání o NTFS je nutné mluvit o clusterech, a ne o sektorech, protože cluster je nejmenší jednotka s jakou tento souborový systém pracuje.

Velikost souboru se ale může často měnit a může nastat situace, kdy již jeho data v jediném souvislém bloku clusterů, který se někdy též označuje jako fragment, udržet nelze. Souborový systém v tomto případě data rozdělí do více fragmentů a jejich polohu zapíše do záznamu, kterým je soubor reprezentován.

Existuje řada nástrojů, jež se snaží data souboru poskládat tak, aby opět tvořila jediný fragment. Tento proces se nazývá defragmentace a používá se za účelem zvýšení rychlosti souborových operací.

Aby autoři těchto programů nemuseli do detailu znát interní struktury souborového systému, které jsou v případě NTFS obchodním tajemstvím, poskytuje ovladač prostřednictvím speciálních zpráv několik funkcí, jež dovolují defragmentaci provádět i bez těchto znalostí. Konkrétně se jedná o tyto zprávy:

Tyto příkazy velmi zjednodušují samotný algoritmus defragmentace. Umožňují totiž zjistit, na jakých clusterech se data souboru nachází, a také nalézt volné místo, kam tyto fragmenty přesunout. Více informací základní algoritmus ani znát nepotřebuje.

Výše popsané rozhraní pro defragmentaci funguje i na souborových systémech FAT.

Mezi další užitečné funkce podporované NTFS patří komprese a šifrování dat souborů. První má za úkol ochránit citlivá data před neautorizovaným přístupem, druhá vlastnost slouží k šetření volného místa.

Komprimované soubory mají ve svých atributech nastaven příznak FILE_ATTRIBUTE_COMPRESSED. Tento atribut může být nastaven i na adresáře; v takovém případě nedochází automaticky ke kompresi všech souborů a složek, které daný adresář obsahuje, ale nové položky budou automaticky vytvářené jako komprimované.

Aplikace mohou zjistit stav komprese souboru také zasláním zprávy FSCTL_GET_COMPRESSION. Z odpovědi ovladače souborového systému se dozví i použitý kompresní algoritmus. Ke zkomprimování souboru slouží zpráva FSCTL_SET_COMPRESSION. Její efekt na adresáře je popsán výše.

Pokud se o to aplikace přímo nezajímají, vůbec nepoznají, že pracují z komprimovanými soubory. Celý proces je plně transparentní a ovladač souborového systému komprimuje a dekomprimuje data souboru podle potřeby.

Proces šifrování a dešifrování také probíhá vůči aplikacím transparentně, pokud uživatel, pod kterým běží, disponuje příslušnými šifrovacími klíči. Na rozdíl od výše popisovaných vlastností pro nastavení šifrování na soubory Windows API exportuje funkce EncryptFile a DecryptFile . Šifrované soubory se vyznačují příznakem FILE_ATTRIBUTE_ENCRYPTED ve svých atributech.

Stejně jako v případě komprese, rutiny pro šifrování a dešifrování lze aplikovat i na adresáře a výsledek je podobný. Nedojde k zašifrování obsahu celé složky, pouze nově vytvářené soubory budou automaticky šifrovány. Dále není možné šifrovat komprimované soubory. Funkce EncryptFile v takovém případě neselže; příslušný soubor je nejdříve dekomprimován a následně zašifrován.

Na rozdíl od systémů FAT, NTFS obsahuje zabudovanou ochranu proti poškození důležitých datových struktur souborového systému například v důsledku výpadku proudu či náhlého restartu počítače. Tato ochrana je implementována prostřednictvím žurnálování – když je potřeba provést nějakou operaci (vytvoření souboru, zápis do souboru), souborový systém potřebné údaje k jejímu provedení nejprve zapíše na speciální místo nazývané log a až potom ji provede. Pokud během vlastního vykonávání operace dojde například k restartu systému, souborový systém má v logu napsáno, co přesně musí udělat, aby danou operaci dokončil. Nemůže se tedy stát, aby aplikace přistupovaly k souborovému systému, kde nějaká operace s jeho datovými strukturami proběhla jen „napůl“.

V případě NTFS probíhá operace nad jeho metadaty v následujících čtyřech krocích:

NTFS pomocí tohoto mechanismu chrání pouze svá vlastní metadata, nikoliv další soubory a složky, které si během své aktivity vytváří různé aplikace. Aplikace si vše musí zajistit samy. Souborový systém jim poskytuje následující možnosti:

Další zajímavou vlastností NTFS související se zaznamenáváním změn souborového systému je tzv. žurnál USN (USN Change Journal). Souborový systém si informaci o každé provedené změně nad souborem či adresářem ukládá stranou do speciálního souboru. O každé změně si pamatuje pouze: její pořadové číslo, jméno cílového objektu, index cílového objektu a jeho rodiče v rámci Master File Table a datum a typ operace. Tyto informace sice nejsou dostatečné například pro odstranění účinků operace, ale umožňují zjistit, s jakými soubory a adresáři operační systém (potažmo uživatel) v poslední době pracoval.

Pořadové číslo operace (Update Sequence Number – USN) nese o něco méně informací než datum provedení. Nedozvíte se z něho, kdy daná operace proběhla, ale můžete s jeho využitím zjistit, jak po sobě jednotlivé operace následovaly. Každý soubor má ve svém záznamu uloženo USN poslední operace, která jej nějakým způsobem změnila; pomocí tohoto čísla ji lze vyhledat v USN žurnálu.

Žurnál USN může být užitečný například pro zálohovací aplikace, které jeho zkoumáním mohou snadno zjistit, jaké soubory a adresáře se od poslední zálohy změnily. Nemusí tak ve většině případů procházet celý strom souborového systému.

Souborový systém ale nedovoluje růst žurnálu USN do nekonečna. A pokud místo pro žurnál dojde, záznamy o nových operacích budou přepisovat záznamy starší. To znamená, že žurnál USN nemusí obsahovat informace o všech změnách, které se v souborovém systému udály od jeho vzniku.

Každou změnu lze v rámci žurnálu USN jedinečně identifikovat pomocí jejího USN a 64bitového identifikátoru žurnálu. V případě znovuvytvoření, smazání žurnálu či přepisování starých záznamů dojde ke změně jeho identifikátoru. Tím jsou informace o starších změnách ztraceny.

Ovladač souborového systému umožňuje s žurnálem USN pracovat pomocí několika speciálních zpráv, které je možné zasílat pomocí funkce Windows API DeviceIoControl:

Základní struktura oddílu formátovaného NTFS je jednodušší než v případě souborových systémů FAT. Celý prostor je rozdělen na alokační jednotky (clustery), které představují nejmenší bloky dat, se kterými souborový systém umí pracovat. Strukturu oddílu znázorňuje obrázek 6.

První sektor plní úlohu boot sektoru a mimo jiné obsahuje informace o poloze nejdůležitější interní datové struktury NTFS – Master File Table (MFT). Detailnější popis formátu boot sektoru najdete v tabulce 9.

MFT je tvořena polem záznamů pevné velikosti, která je obvykle nastavena na 1 KB. Každý obsazený záznam obsahuje informace o některém souboru nebo adresáři. Záznamy lze rozdělit na dva druhy:

Jeden záznam MFT se skládá z hlavičky a série atributů. Jeho strukturu znázorňuje obrázek 7.

Každý atribut reprezentuje data určitého typu, například informace o datu a čase, jméně či seznamu clusterů, kde se nachází data souboru. Každý atribut má několik základních vlastnosti:

Pomocí posloupnosti různých typů atributů je souborový systém NTFS schopen zaznamenat a implementovat všechny potřebné funkce. Podrobněji o popisu některých typů atributů pojednávají následující odstavce.

Jméno položky je obsaženo v těle atributu typu 0x30, který se označuje také jako $FILE_NAME. Tento atribut sám nemá název a jeho obsah, jehož strukturu vidíte na výpisu 2, je vždy umístěn v rámci záznamu MFT.

Položka Name obsahuje jednotlivé znaky jména položky. Délka jména v bajtech je uložena v poli NameLength. NTFS ukládá jména pouze v kódování Unicode. Položka NameType je přítomna z důvodu zpětné kompatibility s krátkými 8 + 3 jmény souborů a složek ze souborových systémů FAT. Pokud je nastavena na 1, pole Name je vyplněno dlouhým jménem. Hodnota 2 implikuje krátké jméno. Záznam MFT může obsahovat více atributů $FILE_NAME, a tak každý soubor či adresář může disponovat jak krátkým, tak dlouhým jménem.

Pomocí atributu $FILE_NAME jsou implementovány i hard linky. Důležitou roli v jejich implementaci hraje prvek DirectoryFileReferenceNumber, který obsahuje číslo bázového záznamu reprezentujícího adresář, ve kterém se objekt nachází. Záznam MFT může obsahovat více atributů $FILE_NAME, přičemž každý z nich může odkazovat na jiný rodičovský adresář. Jeden záznam MFT tedy může reprezentovat více objektů v adresářové stromové struktuře. Jednotlivé atributy $FILE_NAME pak určují, pod jakým jménem se má položka v daném adresáři zobrazit.

Zbývající položky těla atributu $FILE_NAME mohou také obsahovat užitečné informace. NTFS do nich ukládá velikost primárního datového proudu a základní informace (viz atribut $STANDARD_INFORMATION) ve chvíli přejmenování.

Pokud tělo atributu překročí určitou velikost, nevejde se do záznamů MFT a ovladač souborového systému pro něj alokuje potřebný prostor mimo. Namísto těla zapíše do záznamu MFT jejich umístění v podobně seznamu běhů (run list).

Seznam běhů se nachází (stejně jako tělo rezidentního atributu) ihned za hlavičkou atributu a skládá se z nestejně velkých položek, které se označují jako běhy. Každý běh popisuje umístění jednoho fragmentu těla atributu (souvislé oblasti alokovaných clusterů). Ovladač souborového systému se snaží celé tělo umístit do jediného fragmentu.

Jak ukazuje obrázek 8, každý běh se skládá ze tří částí – hlavičky, délky a offsetu. Hlavička je tvořena jedním bajtem, jehož dolní čtyři bity udávají velikost délky a horní čtyři bity velikost offsetu v bajtech. Délka udává velikost fragmentu v clusterech a offset adresu počátečního clusteru. Offset je relativní k adrese počátečního clusteru předchozího běhu. V případně prvního běhu se jedná o adresu počátečního clusteru vzhledem k počátku diskového oddílu.

Ovladač souborového systému interpretuje hodnotu uloženou v části offsetu jako celé číslo se znaménkem, což umožňuje umístit na diskovém oddílu určitý fragment těla před fragment předchozí. Záporný offset má nastavený nejvyšší bit (též zvaný znaménkový) na 1.

Každý seznam běhů je ukončen bajtem hlavičky o hodnotě 0x00, tedy během, který nemá definovánu žádnou délku a ani žádný offset.

Nulové hodnoty se v hlavičce mohou ještě vyskytovat v případě běhů komprimovaných a řídkých souborů. Datové atributy těchto souborů mohou obsahovat fragmenty, jež buď neobsahují žádná užitečná data, nebo se uvolnily po provedení komprese těla atributu. V obou případech není nutné alokovat žádné clustery, a tak hlavička běhů popisujících takové fragmenty obsahuje nulovou velikost položky offsetu. Samotná položka offsetu potom chybí.

Pokud některému z rezidentních atributů narostou data natolik, že se nevejde do záznamu MFT, ovladač souborového systému pro ně alokuje clustery mimo Master File Table, data do nich přesune a v záznamu MFT je nahradí seznamem běhů.

U velkých a fragmentovaných souborů (či adresářů s velkým množstvím položek) může seznam běhů narůst do takových rozměrů, že se do záznamu MFT nevejde. Ovladač souborového systému na tento problém reaguje tak, že v Master File Table alokuje nový záznam, který se stane novým vedlejším záznamem daného souboru či adresáře. Do tohoto záznamu překopíruje celý problémový atribut, nebo jeho část.

Nerezidentní atributy je možné rozdělit na více částí a každou z nich uložit do jiného záznamu MFT. Každá taková část má stejnou strukturu jako atribut, ze kterého vznikla, pouze ve své hlavičce nese informaci, že popisuje umístění dat až od určitého clusteru. Rezidentní atributy rozdělit na více částí nelze.

K vytváření nových vedlejších záznamů může ovladač souborového systému přistoupit také v případě, že záznam MFT obsahuje příliš velký počet atributů, které musí být rezidentní. Tento případ může nastat například u souboru s vysokým počtem hard linků. Každý hard link znamená v cílovém záznamu jeden atribut $FILE_NAME, který musí zůstat rezidentní.

Při vytvoření prvního vedlejšího záznamu daného souboru či adresáře ovladač souborového systému přidá do bázového záznamu speciální atribut, jehož úkolem je držet informace o tom, v jakém záznamu MFT (bázovém či některém z vedlejších) se jednotlivé atributy nacházejí. Tento atribut má číselnou hodnotu typu 0x20 a označuje se jako $ATTRIBUTE_LIST. Jeho tělo je tvořeno posloupností různě dlouhých položek, každá obsahuje informace o umístění jednoho atributu nebo jedné jeho části. Strukturu jedné položky vidíte na výpisu 3.

Cílový atribut je identifikován svým typem (prvek AttributeType) a pořadovým číslem (AttributeNumber). V případě, že položka popisuje umístění části nerezidentního atributu, v poli LowVcn se nachází číslo počátečního clusteru popisovaného úseku dat.

U pojmenovaných atributů si položka pamatuje i jejich jméno. NameLength udává délku jména ve znacích Unicode a NameOffset jeho adresu relativní k počátku struktury ATTRIBUTE_LIST_ENTRY. Položky reprezentující nepojmenované atributy mají hodnotu prvku NameLength nastavenou na nulu.

Délka každé položky seznamu atributů je uložena v poli Length a zahrnuje v sobě jak samotný záznam ATTRIBUTE_LIST_ENTRY, tak prostor spotřebovaný na uložení jména. Jednotlivé záznamy následují těsně za sebou.

Záznamy adresářů v Master File Table vypadají jako záznamy obyčejných souborů, navíc ale obsahují až tři atributy za účelem uložení seznamu položek. Neobsahují žádný primární datový atribut, ale mohou svá data ukládat do pojmenovaných alternativních proudů.

Seznam položek adresáře je ukládán ve formě B* stromu, datové struktury vzdáleně podobné stromům z první kapitoly, která umožňuje rychle vyhledávat podle klíče (zde je jím jméno položky) a dobře funguje i na pomalejších zařízeních, mezi které magnetické pevné disky rozhodně patří. Kořen tohoto stromu je obsažen v atributu typu 0x90, který se označuje jako $INDEX_ROOT a je vždy celý uložen v rámci záznamu MFT. Pokud tedy adresář obsahuje jen malé množství položek, veškeré jeho informace jsou uloženy pouze v Master File Table a při jeho čtení není nutné načítat obsah dalších clusterů.

Pokud se do kořenového stromu uzlu informace o všech položkách adresáře nevejdou, ovladač ntfs.sys vytvoří do záznamu MFT další dva atributy. Atribut typu 0xA0 ($INDEX_ ALLOCATION) není nikdy rezidentní (jeho data se vždy nacházejí mimo MFT) a obsahuje všechny uzly stromu krom kořenového.

Třetím atributem je bitová mapa (typ 0xB0, $BITMAP). Její data se mohou nacházet buď uvnitř záznamu MFT, nebo i mimo něj. Udává, které clustery atributu $INDEX_ALLOCATION jsou aktuálně využity pro uložení obsahu jednotlivých uzlů stromu a které jsou aktuálně volné. Díky přítomnosti tohoto atributu nemusí ovladač souborového systému při každé operaci přidávání či mazání uzlu stromu měnit seznam běhů atributu $INDEX_ALLOCATION, pouze změní obsah některých bitů v $BITMAP, čímž ušetří čas.

Jak ukazuje obrázek 6, NTFS nevyhrazuje příliš mnoho diskového prostoru pro speciální datové struktury, jako tomu bylo v případě souborových systémů FAT (viz obrázek 1). Na obrázku vidíte pouze dvě speciální oblasti: boot sektor a Master File Table. Do zbylého prostoru mohou soubory a adresáře ukládat svá data. Na první pohled se zdá, že NTFS si nikde nepamatuje například seznam volných a obsazených clusterů.

První pohled ale klame hned dvakrát. NTFS si pamatuje seznam volných a obsazených clusterů a další metadata, nevyhrazuje však pro ně speciální oblasti. Ukládá je do souborů a adresářů, umístěních v prvních záznamech Master File Table a nacházejících se v kořenovém adresáři stromové struktury. Ovladač ntfs.sys však jejich přítomnost před souborovými manažery a jinými aplikacemi skrývá. Druhý bod, ve kterém první pohled na NTFS klame, je speciálnost MFT a boot sektoru. Obě tyto struktury jsou reprezentovány soubory na počátku MFT samotné. Jediná specialita boot sektoru spočívá v tom, že jej (na rozdíl od dat ostatních souborů) nelze přesunout do jiné oblasti.

Samotná Master File Table je reprezentována záznamem, který se v ní nachází hned jako první. Fakt, že MFT je v podstatě obyčejný soubor, například znamená, že se může skládat z více fragmentů. Fragmentaci se ovladač souborového systému snaží zamezit tím, že za tabulkou vytváří speciální prostor zvaný zóna MFT (MFT Zone), který se pro ukládání dat obyčejných souborů začne využívat až tehdy, když v jiných oblastech diskového oddílu dojde volné místo. Zóna MFT je rezervována primárně pro rozšiřování Master File Table.

Přehled souborů obsahujících různá metadata najdete v tabulce 11. Kromě názvu a krátkého popisu tabulka obsahuje u každého souboru i index, který určuje pořadové číslo záznamu reprezentujícího daný soubor. Například samotná Master File Table je obsažena v souboru s názvem $MFT, který je uložen v záznamu s indexem 0, tedy vůbec prvním záznamu v tabulce.