Information Technology | Operating systems » Az NTFS fájlrendszerről

Az NTFS fájlrendszerről - dióhéjban 2002.1111 - R4s Az informatikusok és rendszerszintű programfejlesztők alapismeretei közé tartozik a DOS file-rendszerének a FAT típusú lemezkezelésnek az ismerete. A DOS file-rendszerének (végleges formájában MS-DOS 20+) struktúrája már 1983 óta közismert, míg az ugyancsak Microsoft által kifejlesztett NTFS állomány rendszerről vajmi keveset hallhatunk. A Windows NT operációs rendszer NTFS állomány-kezeléséről kívánunk áttekintés jellegű ismertetőt adni. Á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ányrendszerek á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 - 622) í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. Táblázat 1: Alapértelmezett A cluster méretének növelése pedig a fent elmondottak cluster méretek során egyértelműen maga után vonja azt a hely pazarlást, Cluster melyet részint a kis méretű file-ok és az egyéb file-ok A partíció mérete méret tárolásakor fennmaradó helyfelesleg okoz. Az NTFS a 512 MB vagy kisebb 512 byte FAT16-tal szemben nem 16 bites, hanem 64 bites 512 MB - 1024 MB 1 KB indexeket használ a clusterek kiválasztásához, így nem 1024 MB - 2048 MB 2 KB pazarol az amúgy is minduntalan szűkös hellyel, továbbá a 2048 MB vagy több 4 KB 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 1 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 filemű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 2 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. Táblázat 2: NTFS meta-adat file-ok 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 Az MFT A MFT (Master File Table - Mester File Tábla), az NTFS legközpontibb része. Az MFT a DOS filerendszerének a FAT táblájához (file allokációs tábla) hasonlítható, hisz minden file-t, könyvtárat, és metaadat 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 filerendszer ö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, vag y több attri bútu 3 mbó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 "cikkdoc", 2 ábra Mint az ábrán láthatjuk a "cikk.doc"

Táblázat 3: NTFS attribútum típusok Leírás file egy nagyobb file, mely számos - Attribútum típus és nagy méretű - pl. biztonsági (az $VOLUME VERSION A kötet verziója ábrán nem részletezett) $VOLUME NAME A kötet neve NTFS verzió és állapot flag attribútummal rendelkezik, továbbá $VOLUME INFORMATION File vagy könyvtár név eléggé töredezett. Az MFT rekord $FILE NAME A file idő bélyege, rejtett, fejrésze, látható módon definiálja a $STANDARD INFORMATION rendszer, és csak olvasható nevet, az általános információkat alap attribútumok, létrehozási, jellemzők utolsó hozzáférési idő - továbbá $SECURITY DESCRIPTOR Biztonsági információk File adat mutatót tartalmaz a külső attribútum $DATA Könyvtár tartalom adatokra. Az ábrán LCN mutatót $INDEX ROOT Könyvtár tartalom használtunk a partíció más cluster- $INDEX ALLOCATION ire hivatkozó bejegyzések esetén, $BITMAP Könyvtár tartalom míg a VCN az adott - attribútum

elhelyezkedés struktúrán belüli ofszetet adja meg. $ATTRIBUTE LIST A nem beágyazott attribútum fejrészek megadása 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ő - azaz 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 4 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 40 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ó filerendszer) 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ő NTFSsys 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 readmetxt-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 5 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.sysinternalscom 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. Ajánlott irodalmak, források Mark Inside NTFS (http://www.sysinternalscom, 1998) Russinovich NTFS

információkat lekérdező program (Mark Russinovich, NTFSinfo 1997) Helen Custer Inside the Windows NT File System (Microsoft Press, 1994) Rajeev Nagar Windows NT File System Internals (OReilly 1997) 6