Áttekintés, FAT kontra NTFS

A Windows NT fejlesztése során a Microsoft kifejlesztette az 1980-as évek vége felé az NT natív file-rendszerét, az NTFS-t (NTFS - New Technology File System - Új technológiájú file-rendszer). Az NTFS a Windows NT felépítéséhez hasonló elveken és elvárásokon alapul, egy megbízható, biztonságos, a gyors merevlemez méret fejlődéssel és egyéb újításokkal lépést tartó rendszert kívántak tervezni. A fejlesztés korai szakaszában csak a FAT16 és HPFS file-rendszer volt az x86-os operációs rendszereken elterjedve, majd a merevlemezek méretének növekedésével egyértelműen látszott a FAT16 pazarló hátránya, ekkor kezdett az NTFS teret hódítani. Az állomány-rendszerek általában a lemezt diszkrét részekre, alap egységekre bontják ezek a clusterek. (A clustereknél nincsen operációs rendszer szinten, programozó által, szabványos API hívásokkal elérhető kisebb lemezegység, viszont fizikai szinten, maga az operációs rendszer magjának része, a lemezvezérlő rutinok ennél kisebb, szektor szintű műveleteket is végeznek, ezzel megvalósítva a clusterek írását, olvasását.) Egy cluster a lemez fizikai szektorának egész számú többszöröséből állhat. Lévén, hogy a cluster a legkisebb kezelhető lemezegység, így 10 byte-os szöveges állományunk is 4 KB-ot foglal a lemezen fizikailag FAT, 4 KB-os cluster rendszer esetén.
Mivel a FAT struktúrája definiálja, hogy maximum 65526 cluster helyezkedhet el egy FAT16 partíción (FAT16: DOS 2.0 - 6.22) így, ha nagyobb winchestert vásárolunk a cluster méretet kénytelen növelni a formázó program, hogy egy partícióval lefedhessük merevlemezünket. 

A partíció mérete
 Cluster méret 
512 MB vagy kisebb 
512 MB - 1024 MB
1024 MB - 2048 MB
2048 MB vagy több
512 byte
1 KB
2 KB
4 KB
Táblázat 1: Alapértelmezett cluster méretek
A cluster méretének növelése pedig a fent elmondottak során egyértelműen maga után vonja azt a hely pazarlást, melyet részint a kis méretű file-ok és az egyéb file-ok tárolásakor fennmaradó helyfelesleg okoz. Az NTFS a FAT16-tal szemben nem 16 bites, hanem 64 bites indexeket használ a clusterek kiválasztásához, így nem pazarol az amúgy is minduntalan szűkös hellyel, továbbá a takarékos és biztonságos adat-tárolású tulajdonsága révén előretörhetett. Megjegyzem, hogy az NTFS nem csak a takarékossága révén terjedt el később, hanem elég nagy erőforrás igénye van, így csak később a gyorsabb processzorral és főképp nagyobb memóriával ellátott - eleinte - szervereknél volt érdemes alkalmazni. A 64 bites indexeknek köszönhetően elvileg az NTFS partíció mérete 16 EB (exabyte !) lehet, de a gyakorlatban 2 TB-nál (terrabyte) nagyobb partíciókat nem kezel, s valljuk be, egyenlőre nincs is szükség rá.

Az NTFS fejlesztői nem estek a HPFS (High Performance File System, IBM, OS/2) tervezőinek hibájába - a két fejlesztői gárda között átfedés volt -, az adatbiztonság és titkosság alapvető szerepet játszott már az alapok kialakításánál, így teljesen a Windows NT biztonsági modelljére épül. A DACL (Discretionary Access Controll List) és SACL (System Access Controll List), avagy hozzáférési listák biztonsági megfontolásaira épül, így megadható ki mikor és mit végezhet egy file-lal, továbbá minden végzett művelet visszakövethető. Ez a biztonsági modell, mely valóban az NTFS mellett szól egy több felhasználós környezetben, Windows NT szerver esetén feltétlenül, vagy akár egy NT munkaállomás esetén is. A FAT-tal ellentétben az NTFS az első olyan Microsoft platformú file-rendszer, mely támogatta a hosszú file-neveket: maximum 255, akár Unicode karakterrel. A FAT továbbfejlesztéseként jött létre a Windows 95 által bevezetett VFAT, mely abszolút kompatíbilis elődjével, ugyanakkor megengedi a hosszú, 255 karakteres file-azonosítók használatát. Az NTFS továbbá lehetőséget nyújt több fizikai partíció egy logikai meghajtóként történő használatára (volume set - kötetkészlet, stripte set - csíkkészlet).

A FAT-tal ellentétben az NTFS megengedi, hogy több adatfolyam (alternate data streams) lehessen egy file-on belül. Ennek magyarázatára legegyszerűbb, ha veszünk egy példát. Begépelve az alábbi parancsot: "notepad proba.txt" hatására a NOTEPAD (jegyzettömb) program új file nyitását jelzi. A szövegfile-ba gépelve és elmentve, kiléphetünk a programból. Majd az alábbi már kicsit különböző parancsot begépelve: "notepad proba.txt:kukucs" hasonlóan a NOTEPAD jelenik meg, és újra egy új file nyitását jelzi, holott már van proba.txt file-unk. A magyarázat az, hogy a második esetben már egy különböző adat stream-et nyitottunk meg. A második esetben a file-t elmentve észrevehetjük, hogy az előző file mérete, tartalma nem változott, s a második file neve nincs is feltüntetve a könyvtár listában. Így ennek a módszernek az az előnye, hogy létrehozhatunk olyan file-okat, melyeket csak azok tudnak megnyitani, akik ismerik a stream nevét. Ezzel az NTFS adatvédelmén kívül - az adott felhasználóhoz rendelt jogosultságon kívül - olyan megoldást is választhatunk, hogy az adott könyvtárra jogosultsággal rendelkező elől is elrejtsünk file-okat. (Amennyiben csak stream névvel rendelkező file-t hozunk létre, akkor egy 0 byte-os stream megnevezés nélküli file is létrejön.) Viszont mielőtt ilyen rejtett file-okkal árasztanánk el winchesterünket, fel kell hívnom a figyelmet, hogy ezen, több adatfolyamú file-okat törölni felettébb nehézkes, és felderíteni se lehet, hogy ki milyen file-okhoz rendelt további stream-eket. Így kerüljük ezek használatát, ekkor nem esünk abba a hibába, hogy "hova tűnt x MB helyem".

Végezetül a FAT hibáit felsorolva, szükséges megemlíteni, hogy nem rendelkezik semmilyen hibatűrő megoldással, avagy a nyitott file-ok módosítása során fellépő rendszerhiba - számítógépünk lefagyása - esetén, a partíción tárolt adataink inkonzisztenssé válhatnak. (Ez a Windows 95/98 rendszerek lefagyása során gyakran eltűnt cluster-ekként jelentkezik.) Szemben az NTFS megoldásával, mely beépített file-műveletvégzési nyilvántartást (log file-t) vezet, így minden file művelet során egy bejegyzést ír a speciális log file-ba. Amikor file művelet során lefagy számítógépünk, az újra bootolás során a log file-ok segítségével azonnal megállapítható, hogy történt -e adatvesztés, és el kell -e indítani a CHKDSK programot (így ne lepődjünk meg, ha nagy munka közben, lefagyás után nem veszett el semmi, és felesleges a lemez ellenőrzőt nekünk elindítani). Amennyiben történt adatvesztés - az-az jelzi a log file, hogy file művelet félbemaradt - a CHKDSK program a log file-t használva megpróbálja visszaállítani az eredeti állapot. Ezen log file egy bejegyzése két típusú lehet, vagy ismétlő (redo) vagy visszavonó (undo) parancsot tartalmazhat. Például: egy file törlése során lefagy számítógépünk, ekkor a visszaállítás során kiderül, hogy az adott file nem lett törölve, a módosítás befejezve, így a művelet újra végrehajtandó. A másik, a visszavonás esetében például: egy file-hoz fűzünk egy másikat, és a file méret illetve hozzáférési dátum beállításánál fagy le számítógépünk. Ekkor a hibajavítás az eredeti állapot visszaállításából áll: eredeti file méret és dátum megadása. A log file mérete a lemeztől függően 2 és 4 MB között lehet. A log file hamar betelne, ha az NTFS nem vizsgálná meg, hogy az ismétel és visszavonás információk szükségesek -e hibajavítás esetére. Ennek elkerülése végett az összes módosított adatot lemezre menti az NTFS és törli a log file tartalmát. Ez a vizsgálat - határpont képzés - kb. minden 4-5 másodpercben megtörténik.

NTFS lemezkezelés

Windows NT alatt a lemezfelügyelő (Disk Administrator - windisk.exe) és a parancssorban futtatható format paranccsal hozhatunk létre NTFS lemez partíciókat és logikai meghajtókat. Mindkettővel meghatározhatjuk a pontos cluster méretet, és ezt érdemes mindig megadnunk, ugyanis -e hiányában az alapértelmezett cluster méretet fogja alkalmazni, ami nem biztos, hogy mindig előnyös. Külön felhívom a figyelmet, hogy Windows NT 4.0 telepítés során megformázott NTFS partíciók mindig 512 byte-osak (1 szektor / cluster) lesznek, így érdemes előre, egy másik NT gép alól megformázni 4 KB-osnál nem nagyobb cluster-méretűre a cél partíciót. A FAT-nál említett pazarlás itt is előállhat a nagy - és nem ajánlott - cluster méretek esetén, ugyanakkor kicsi (pl.: 512 byte-os) cluster méret se ajánlatos, mert a sok cluster-rel történő műveletvégzés is teljesítmény-csökkentő tényező lehet. Az 1-es táblázat összefoglalja az alapértelmezett cluster méreteket.

A file-ok és könyvtárak adatai mellett, az NTFS számos file-t használ a lemezkezeléssel összefüggő adatok tárolása végett. Ezekben a file-okban és más NTFS-sel kapcsolatos file illetve könyvtárban tárolt adatok összességét meta-adatnak (metadata) nevezzük. Egy NTFS partíció formázása során 11 ilyen meta-adat file jön létre, ezeket a 2. táblázat foglalja össze. A meta-adat file-ok Windows NT Intézőből, vagy a DIR parancs hatására sem láthatóak, viszont, ha tudjuk mi a meta-adat file neve, akkor kilistáztathatjuk, dátumát, méretét. Parancssorból begépelve használható a: "DIR /AH $MFT" parancs, mely visszaadja a méretet és dátumot. (A meta-adat file-ok olvasása természetesen nem engedélyezett.)

Az $MFT és $MFTMIRR file-okat alább bővebben áttekintjük, a $LOGFILE meta-adat file-ról pedig már fent szót ejtettünk. A $BADCLUS meta-adat file-t akkor használja az NTFS, ha nem tud beolvasni egy file-t a partícióról, ekkor - ha lehet - más helyre másolja a - megmenthető - adatot és feljegyzi a hibás cluster-t, hogy később ne használja. Ez a felhasználó számára fel sem tűnik, szemben a FAT "Abort, Retry, Fail?" üzenetével. A $BITMAP file egy bit tömb, melynek elemei minden egyes cluster-t jegyeznek, ha az adott bit értéke 1, akkor az a cluster foglalt, ellenkező esetben szabad.
  

Név
MFT rekord
Leírás
$MFT
0
Master File Table
$MFTMIRR
1
Az MFT első 16 rekordjának másolata
$LOGFILE
2
Tranzakciós log file
$VOLUME
3
Tartalmazza a kötet nevét, idő bélyegét, és állapot flag-et
$ATTRDEF
4
Attribútum definíciók
.
5
A partíció főkönyvtára
$BITMAP
6
A partíció cluster térképet tartalmazza (használt - szabad)
$BOOT
7
A partíció boot rekordja
$BADCLUS
8
A partíció hibás cluster-einek listája
$QUOTA
9
A felhasználók lemez kvóta információját tartalmazza (Windows 2000+)
$UPCASE
10
A kisbetűs karaktereket a nagybetűs megfelelőjévé alakítja
Táblázat 2: NTFS meta-adat file-ok
Az MFT

A MFT (Master File Table - Mester File Tábla), az NTFS legközpontibb része. Az MFT a DOS file-rendszerének a FAT táblájához (file allokációs tábla) hasonlítható, hisz minden file-t, könyvtárat, és meta-adat file-t magába foglal. Az MFT különálló egységekből, rekordokból áll. Az NTFS egy vagy több MFT rekordot használ egy file vagy könyvtár meta-adatainak (biztonsági információk, általános attribútumok), illetve annak elhelyezkedési jellemzőjének tárolására. Mivel az MFT maga is egy file az NTFS MFT rekordokat használva állapítja meg elhelyezkedését, méretét. Ez a felépítés teszi lehetővé, hogy az MFT növekedjen (ha új file-ok adatait kell eltárolni), vagy mérete csökkenjen a meta-adatok helyszükségének függvényében. Továbbá, nem szabad elfelejteni, hogy az MFT file lévén, ugyanúgy töredezhet méretváltozása során, akár egy közönséges file.

Az NTFS a file-okat, illetve könyvtárakat az MFT rekordok alapján azonosítja, mely megadja a hozzá társított meta-adatok kezdő címét. Például láthatjuk a 2-es táblázatban, hogy vannak előre definiált MFT rekordok, melyek a rendszer meta-adatokat tartalmazzák.

Az NTFS újabb adatbiztonsági eljárása, hogy az MFT első 16 rekordját a partíción máshol is - általában a partíció közepén - eltárolja, ezt mutatja meg az $MFTMIRR meta-adat file. Megjegyzem, hogy DOS esetén két teljes FAT másolat is létezik, így a file helyfoglalási tábla a "lehető legnagyobb" biztonságban van. NTFS esetén nincs az egész MFT nagy mérete miatt kétszer eltárolva, így ha pont a nem eltárolt rekordok sérülnek meg, kilátástalan a helyreállítás. Továbbá fontos azt is megemlíteni, hogy hiába van a DOS-nál kétszer is eltárolva a FAT, hiba esetén nem képes javítani magát (sőt). Ellenben ha az MFT olvasása során hiba lép fel, az NTFS automatikusan az MFT tükör (MFT mirror) file-t olvassa be, helyét az NTFS partíció boot rekordjából állapítja meg, ahol az $MFT helye is tárolva van.

Mivel az MFT-t is file-ként kezeljük méretváltozása során töredezhet, mely jelentősen csökkentheti a file-rendszer összteljesítményét azáltal, hogy nem olvasható be sorosan az egész MFT, hanem külön - külön lemezművelet kell az egyes rekordok számára. Ez a töredezés úgy jöhet létre, hogy az NTFS nem tudja lefoglalni az MFT teljes méretét - a dinamikus helykihasználás miatt -. Ha az MFT növekedne és már foglaltak - a kevés hely miatt - az MFT után közvetlenül elhelyezkedő cluster-ek, az MFT a maradék, nem összefüggő cluster-területen tud újabb rekordokat létrehozni. Az MFT töredezésének elkerülésére találták ki az MFT zónát, mely bizonyos számú cluster-t foglal le az MFT körül, így nagyobb az esélye, hogy összefüggő területen, vagy az MFT darabok egymáshoz közel helyezkedjenek el. Az MFT zónába file illetve könyvtár adata nem kerülhet. Amennyiben a partíció kezd betelni, és nincs máshol szabad hely, akkor az MFT zónába is írhatunk, viszont ekkor - a kevés szabad hely esetén - az MFT biztosan töredezik. Az MFT töredezettség mentesítése, pedig egy elég bonyolult probléma - az NTFS API felépítése miatt - amit csak a legújabb NTFS defragmentálók tudnak megoldani (Diskeeper 5.0, Speed Disk 5.0).

MFT rekordok

Az MFT rekordok egy kis méretű fejlécből, mely alap információkat tartalmaz a rekordról, majd egy, vagy több attribútumból állnak. Az attribútumok a rekordhoz tartozó adat vagy a file illetve könyvtár sajátosságait adják meg. Az 1-es ábra egy általános MFT rekord felépítését mutatja meg. A fejrész sorszámot tartalmaz az ellenőrzéshez, egy mutatót az első attribútumra, egy újabb mutatót az első szabad byte-ra a rekordban, és a file kezdő MFT rekordjának számát, ha az nem az első. Az NTFS 14 különböző attribútumot használ, hogy minden információt eltárolhasson egy file vagy könyvtárról, az attribútumokat a 3-as táblázat foglalja össze. A lemezen tárolt attribútumok két részre vannak osztva, a fejlécre, mely az attribútum nevét, állapot biteit (flag-jeit) és helyét határozza meg, továbbá az attribútum másik fele az adat rész. Az NTFS az attribútum adatot amennyiben lehetséges megpróbálja az MFT-ben tárolni, ekkor beágyazott (resident) attribútumról beszélünk, amennyiben nem lehetséges - nem fér el az egész attribútum az MFT rekordban -, akkor külső cluster-eken tárolja az attribútum adatot és ez esetben külső (non-resident) attribútumról beszélünk. A beágyazott illetve külső attribútum elhelyezkedést az MFT rekord mérete korlátozza, mely az esetek döntő többségében 1 KB. A beágyazott attribútumok esetén - magától értendően - a fejléc az MFT-n belüli helyre, míg külső elhelyezésnél a tároló cluster-re mutat. A file-név, illetve általános és biztonsági információk mindig kötött módon az MFT-be beágyazva kerülnek eltárolásra. Lássunk egy példát egy általános file felépítésére, legyen ez a "cikk.doc", 2. ábra.

 
Attribútum típus
Leírás
$VOLUME_VERSION A kötet verziója
$VOLUME_NAME A kötet neve
$VOLUME_INFORMATION NTFS verzió és állapot flag
$FILE_NAME File vagy könyvtár név
$STANDARD_INFORMATION  A file idő bélyege, rejtett, rendszer, és csak olvasható jellemzők
$SECURITY_DESCRIPTOR Biztonsági információk
$DATA File adat
$INDEX_ROOT Könyvtár tartalom
$INDEX_ALLOCATION Könyvtár tartalom
$BITMAP Könyvtár tartalom elhelyezkedés
$ATTRIBUTE_LIST A nem beágyazott attribútum fejrészek megadása
Táblázat 3: NTFS attribútum típusok
Mint az ábrán láthatjuk a "cikk.doc" file egy nagyobb file, mely számos - és nagy méretű - pl. biztonsági (az ábrán nem részletezett) attribútummal rendelkezik, továbbá eléggé töredezett. Az MFT rekord fejrésze, látható módon definiálja a nevet, az általános információkat - alap attribútumok, létrehozási, utolsó hozzáférési idő - továbbá mutatót tartalmaz a külső attribútum adatokra. Az ábrán LCN mutatót használtunk a partíció más cluster-ire hivatkozó bejegyzések esetén, míg a VCN az adott - attribútum - struktúrán belüli ofszetet adja meg. NTFS alatt lehetőség van a file-ok adat-részének natív tömörítésére is, ekkor 16 cluster-es egységben tárolja a file-ok adatfolyamait.
 

Könyvtárak

Az NTFS alatt a könyvtár egy index attribútum, amelyet a file-nevek tárolására és egyeztetésére hoz létre a file-rendszer. A könyvtárbejegyzés tartalmazza a file nevét és az általános attribútumainak másolatát, így az NTFS gyors listázást tesz lehetővé anélkül, hogy be kellene olvasnia a file-ok MFT rekordjait. Amikor a könyvtár bejegyzési adatai beleférnek egy MFT rekordba, akkor egy attribútum az index root (fő index) - lásd 3-as táblázat - írja le a bejegyzéseket, illetve elhelyezkedésüket. Ahogy a könyvtár nő - az-az egyre több új könyvtár nyílik belőle -, úgy elfogyhat az MFT rekordban a hely, így külső index bufferekre van szükség, mely eltárolja a további könyvtár-bejegyzéseket. Ez esetben egy újabb, az index allocation attribútum fejrésze mutatja meg a 4 KB-os bufferek helyét a partíción. A buffereken belül - az index root, az MFT-hez hasonlóan - egy könyvtárbejegyzés mérete változhat a file-név méretének függvényében.

Ahhoz, hogy még gyorsabb listázást tegyen lehetővé az NTFS, az index root (fő index) és index allocation bufferben előrendezetten, abc sorrendben, növekvőleg tárolja a könyvtár-bejegyzéseket. Az index allocation attribútum a beágyazott és külső attribútumokhoz hasonlóan sorrendi - VCN - elhelyezkedési információt tartalmaz. A 3-as ábra jól szemlélteti egy könyvtár egyszerűsített felépítését. Csupán pár bejegyzést - s azokat is külön index bufferekben - használunk az egyszerű áttekinthetőség végett. Az ábra piros nyilai mutatják, hogy az NTFS hogyan járja be a könyvtár bejegyzéseket egy listázás - avagy keresés - során. A fekete nyilak mutatják, hogy az index allocation attribútum hogyan hivatkozik a - külső - bufferekre.

Windows 2000 NTFS (NT 5.0 NTFS)

A Windows NT platform fejlesztése során a file-rendszer, az NTFS is fejlődik, számos szükséges megoldást csak most, az új NT 5.0 verzióval (Windows 2000) implementálnak. Az egyik már szükségessé vált szolgáltatás a partíció titkosítása, ugyanis eddig kódolás nélkül tartalmazott minden adatot, így a DOS és Windows 95/98 alatt működő NTFS partíció olvasó program az NTFSDOS segítségével bármely egyébként titkos információ elérhető volt. Azért nem alkalmaztak eddig semmilyen kódolást, mert egyszerűen nem volt szükség rá, hisz nem volt használható NTFS partíció olvasó segédprogram DOS vagy más platform alá. Az NTFSDOS program ellen Windows NT 4.0 alatt a 4 KB-nál nagyobb méretű cluster-ek használata jelent némi védelmet - mert csak 4 KB-os cluster méretig tud dolgozni -, igaz ekkor a töredezettség mentesítő programok se működnek partíciónkon. Az új titkosítási eljárás lényege, hogy nem maga az NTFS titkosítja az adatokat, hanem egy EFS (Encrypting File System - Tikosító file-rendszer) az NTFS-hez közel álló vezérlő program oldja ezt meg. Amikor a felhasználó titkosítani kíván egy file-t, akkor az NTFS átnyújtja az adatot az EFS-nek, amely a SID-et (Security ID - Biztonsági szám, minden NT szerver illetve állomásra jellemző) és a DES (Data Encryption Standard) kódoló illetve dekódoló egységét használja a titkosításhoz.

További újítás a lemezkvóta implementálása, melynek segítségével megadhatjuk egy felhasználó által "bitorolható" hely nagyságát a partíción. A $QUOTA meta-adat már létezett a korábbi NTFS verziókban is, csak nem implementálták felhasználását. Most az $EXTEND meta-adat használatának segítségével eltárolhatóak a helyfoglalások feljegyzései.

Végezetül az újítások sorában egy üdvözlendő segédprogram, egy töredezettség mentesítő (defragmentáló) kapott helyet. Ez az Executive Software Diskeeper programjának egy "lebutított" verziója. (Mely valójában a NT 4.0 óta jól működő NTFS defragmentation API-t használja.)

Az új NTFS verzióval kapcsolatban fontos a kompatibilitás kérdése. Az új verzió - mint általában - már bőven tartalmaz annyi újítást, hogy a régi NTFS vezérlő-programokkal (NTFS.sys) ne lehessen együtt használni, így egy frissített, a már NTFS 5.0-s verziót is kezelő NTFS.sys driver-re van szükség, ami már a Service Pack 4 (SP4) része. Ez képes írni, olvasni a Windows 2000 alatt formázott, új verziójú NTFS partíciókat, míg a speciális titkosítási, és lemezkvóta újdonságok illetve a lemez ellenőrző (chkdsk) már nem használható. Továbbá az SP4 readme.txt-jében megemlítik, hogy ne lepődjünk meg, ha Windows 2000 boot-olása során a chkdsk lemez- ellenőrző illetve javító programot indítja el, a Windows NT 4.0 SP4-es NTFS driver-rel NTFS 5.0-s partícióra történő írás után.
 

Szumma-szummárum

Még ebben az egyszerű, részletekbe egyáltalán nem bocsátkozó az NTFS-ről szóló áttekintésünkből is kitűnik, hogy valóban összetett és bonyolult file-rendszerről van szó. Megtalálható NTFSinfo nevű program (EXE, illetve forráskód: Visual C), mely példát nyújt egy NTFS partíció általános adatainak lekérdezésére. A program és még számos NT-vel kapcsolatos információ fellelhető a http://www.sysinternals.com web címen. Az alábbi táblában a cikkhez felhasznált forrás mellett (Mark Russinovich - Inside NTFS, Windows NT Magazine, 1998) található még pár, a konkrétumok iránt érdeklődő Olvasóknak ajánlott - egyébként nehezen beszerezhető - irodalom, mely fejlesztői információkkal szolgál.
 
 

Mark Russinovich Inside NTFS (http://www.sysinternals.com, 1998)
NTFSinfo NTFS információkat lekérdező program (Mark Russinovich, 1997)
Helen Custer Inside the Windows NT File System (Microsoft Press, 1994)
Rajeev Nagar Windows NT File System Internals (O'Reilly 1997)
Ajánlott irodalmak, források
 

A cikk, a PC World 1999. decemberi számában található meg. A kiadó és cikkíró engedélyével jelentettük meg. Minden jog fenntartva, IDG Magyarország Lapkiadó Kft és ProgHu - Magyar Programozási Oldalak.