A FAT ( angolul File Allocation Table "file allocation table") egy klasszikus fájlrendszer - architektúra , amelyet egyszerűsége miatt még mindig széles körben használnak flash meghajtókhoz . Hajlékonylemezekben , memóriakártyákban és más adathordozókban használatos . Korábban merevlemezeken is használták.
Bill Gates és Mark McDonald fejlesztette ki 1976-1977 között [1] [2] . Az MS-DOS és a Windows 9x család operációs rendszereinek fő fájlrendszereként használták .
A FAT-struktúra az ECMA-107 szabványt követi, és részletesen a Microsoft FATGEN néven ismert hivatalos specifikációja [3] határozza meg .
A FAT-nak négy változata létezik - FAT12 , FAT16 , FAT32 és exFAT (FAT64) . Különböznek a lemezszerkezet rekordjainak bitességében, vagyis a fürtszám tárolására fenntartott bitek számában. A FAT12 főként hajlékonylemezekhez , a FAT16 pedig kis lemezekhez használatos. A FAT alapján új exFAT (extended FAT) fájlrendszert fejlesztettek ki, amelyet elsősorban flash meghajtókhoz használnak .
Kezdetben a FAT nem támogatta a hierarchikus könyvtárrendszert – minden fájl a lemez gyökerében volt. Ez az egyszerűség kedvéért történt, mivel a mindössze 160–180 KB kapacitású egyoldalas hajlékonylemezeken egyszerűen nem volt értelme néhány fájlt könyvtárakba rendezni. A 320 kilobájtos vagy annál nagyobb lemezek elterjedésével az összes fájl gyökérben való tárolása kényelmetlennek bizonyult, emellett a gyökérkönyvtár kis mérete korlátozta a lemezen lévő fájlok számát. A címtárak az MS-DOS 2.0 kiadásával jelentek meg .
A különböző operációs rendszerek különböző FAT-bővítményeket is megvalósítottak. Például a DR-DOS további fájlhozzáférési attribútumokkal rendelkezik; Windows 95 , Linux alatt - támogatja a hosszú fájlneveket (LFN) Unicode formátumban (Virtual FAT - VFAT); OS/2 rendszeren az összes fájl kiterjesztett attribútumai.
A VFAT a Windows 95 rendszerben bevezetett FAT-kiterjesztés . A FAT-ban a fájlnevek 8.3 formátumúak , és csak ASCII karakterekből állnak . A VFAT-hoz hozzáadták a hosszú (legfeljebb 255 karakteres) fájlnevek ( Long File Name, LFN ) UTF-16LE kódolású támogatását , míg az LFN-eket a 8.3-as formátumú nevekkel egyidejűleg tárolják, visszamenőleg SFN-nek ( angol rövid fájlnév ) hívják. Az LFN-ek nem tesznek különbséget a kis- és nagybetűk között a keresés során, azonban a nagybetűkkel tárolt SFN-ekkel ellentétben az LFN-ek megtartják a fájl létrehozásakor megadott kis- és nagybetűket [4] [5] .
A FAT fájlrendszerben a szomszédos lemezszektorokat fürtöknek nevezett egységekre egyesítik . A klaszterben lévő szektorok száma kettő hatványával egyenlő (lásd alább). Egész számú fürt (legalább egy) van lefoglalva a fájladatok tárolására, így például ha a fájl mérete 40 bájt, a fürt mérete pedig 4 KB, akkor a számára lefoglalt helynek csak 1%-a lesz ténylegesen a fájl információi foglalják el. Az ilyen helyzetek elkerülése érdekében célszerű csökkenteni a fürtök méretét, és fordítva, csökkenteni a címinformáció mennyiségét és növelni a fájlműveletek sebességét. A gyakorlatban valamilyen kompromisszumot választanak. Mivel előfordulhat, hogy a lemezkapacitás nem egész számú fürtben fejezhető ki, általában a kötet végén úgynevezett többletszektorok találhatók – egy fürtnél kisebb „maradvány”, amelyet az operációs rendszer nem tud lefoglalni információk tárolása.
A FAT32 kötettér logikailag három összefüggő területre oszlik:
A FAT12 és a FAT16 rendelkezik egy dedikált területtel is a gyökérkönyvtár számára. Rögzített pozícióval (közvetlenül a FAT tábla utolsó eleme után) és 32 bájtos elemekben fix mérettel rendelkezik, vagyis a Partition Boot Record leírásánál pontosan a 32 bájtos elemek száma van feltüntetve. , amelyek mindegyike leírja a gyökérkönyvtár bármely elemét (legyen az fájl vagy más alkönyvtár).
Ha egy fürt egy fájlhoz tartozik, akkor a FAT tábla megfelelő cellája tartalmazza ugyanazon fájl következő fürtjének számát. Ha a cella a fájl utolsó fürtjének felel meg, akkor az egy speciális értéket tartalmaz (0xFFFF FAT16 esetén). Így létrejön a fájlfürtök lánca. A nullák a táblázat nem használt klasztereinek felelnek meg. A „rossz” fürtök (amelyek például ki vannak zárva a feldolgozásból, mert az eszköz megfelelő területe olvashatatlan) szintén rendelkeznek egy speciális kóddal (0xFFF7 FAT16 esetén).
Fájl törlésekor a név első karakterét a 0xE5 speciális kód helyettesíti, és a fájl fürtlánca a kiosztási táblázatban nullára áll vissza. Mivel a fájlméretre vonatkozó információ (amely a fájlnév melletti könyvtárban található) érintetlen marad, ha a fájlfürtök egymás után helyezkedtek el a lemezen, és nem írták felül őket új információkkal, a törölt fájl visszaállítható.
A FAT-kötet első szerkezetét BPB-nek ( BIOS - paraméterblokknak ) hívják, és egy lefoglalt területen, a nulladik szektorban található. Ez a struktúra a fájlrendszer típusát és az adathordozó (hajlékonylemez vagy merevlemez-partíció) fizikai jellemzőit azonosító információkat tartalmaz.
BIOS Parameter Block (BPB)A BPB hiányzott az MS-DOS 1.x-et kiszolgáló FAT-ból, mivel akkoriban csak kétféle kötetet feltételeztek - egyoldalas és kétoldalas öt hüvelykes 320 KB-os hajlékonylemezeket, a kötet formátumát pedig a a FAT terület első bájtja. A BPB-t 1983 elején vezették be az MS-DOS 2.x-ben, mint kötelező rendszerindító szektor szerkezetet, amelyből ezentúl meg lehet határozni a kötetformátumot; a régi FAT első bájt felismerési séma már nem támogatott. Az MS-DOS 2.0-ban is bevezették a fájlok és mappák hierarchiáját (ezelőtt minden fájl a gyökérkönyvtárban volt tárolva).
Az MS-DOS 2.x BPB-struktúrája 16 bites "szektorok teljes száma" mezőt tartalmazott, ami azt jelentette, hogy a FAT ezen verziója alapvetően nem alkalmazható 2 16 = 65 536 szektornál nagyobb, azaz 32 MB-nál nagyobb kötetekre. 512 bájt szabványos szektormérettel. Az MS-DOS 4.0-ban (1988) a BPB mezőt 32 bitesre bővítették, ami az elméleti kötetméret 232 = 4 294 967 296 szektorra, azaz 2 TB-ra növelését jelentette 512 bájtos szektorral.
A BPB következő módosítása a Windows 95 OSR2-vel jelent meg, amely bevezette a FAT32-t (1996 augusztusában). A kötetméret 2 TB-os korlátja megszűnt, egy FAT32-es kötet elméletileg akár 8 TB-os is lehet. Az egyes fájlok mérete azonban nem haladhatja meg a 4 GB-ot. A FAT32 BIOS-paraméterblokkja a FAT korábbi verzióival való kompatibilitás érdekében megismétli a FAT16 BPB-jét a BPB_TotSec32 mezőig bezárólag, amit a különbségek követnek.
A FAT32 "boot szektor" valójában három 512 bájtos szektor - a 0, 1 és 2 szektorok. Mindegyik tartalmazza a 0xAA55 aláírást a 0x1FE címen, vagyis az utolsó két bájtban, ha a szektor mérete 512 bájt. Ha a szektor mérete meghaladja az 512 bájtot, akkor az aláírás mind a 0x1FE címen, mind a nulla szektor utolsó két bájtjában található, azaz megkettőződik.
FSIinfoA FAT32-partíció rendszerindító rekordja egy FSInfo nevű struktúrát tartalmaz, amely a kötet szabad fürtszámának értékét tárolja. Az FSInfo általában az 1. szektort foglalja el (lásd a BPB_FSInfo mezőt), és a következő szerkezettel rendelkezik (a szektor elejéhez viszonyított címek):
Az FSInfo bevezetésének lényege a rendszer működésének optimalizálása, hiszen a FAT32-ben az indexmutató tábla igen nagy méretű lehet, bájtonkénti kikeresése pedig jelentős időt vehet igénybe. Előfordulhat azonban, hogy az FSI_Free_Count és FSI_Nxt_Free mezők értékei nem felelnek meg a valóságnak, ezért ellenőrizni kell a megfelelőséget. Ráadásul még az FSIinfo mentésben sem frissülnek, ami általában a 7-es szektorban található.
A FAT kötet típusának meghatározásaA kötet FAT típusának meghatározását (vagyis a FAT12, FAT16 és FAT32 közötti választást) az operációs rendszer a kötetben lévő fürtök száma alapján határozza meg, amelyet viszont a BPB mezők határoznak meg. Először is ki kell számítani a gyökérkönyvtár szektorainak számát:
RootDirSectors = (BPB_RootEntCnt * 32) / BPB_BytsPerSecEzt követően meghatározzuk, hogy a BPB_FATSz16/32 és BPB_TotSec16/32 mezők közül melyik nem egyenlő nullával, és ezeket használják a kötet adatterület szektorainak számának meghatározására:
DataSec = TotSec - (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) + RootDirSectors)Végül meghatározzuk az adatterület-klaszterek számát:
CountofClusters = DataSec / BPB_SecPerClus
A fürtök száma alapján egy az egyhez megfelelés van a fájlrendszerrel:
A hivatalos specifikáció szerint ez az egyetlen érvényes módja a FAT típus meghatározásának. A megadott leképezési szabályokat sértő kötet mesterséges létrehozása azt eredményezi, hogy a Windows helytelenül kezeli azt. Javasoljuk azonban, hogy kerülje a CountofClusters olyan értékeit, amelyek közel állnak a kritikus értékekhez (4085 és 65525), hogy megfelelően meghatározhassa a fájlrendszer típusát bármely, gyakran hibásan megírt illesztőprogram által.
A FAT12 formázáskor mindig hajlékonylemezen jön létre. Ami a merevlemezeket és a flash meghajtókat illeti, legfeljebb 512 MB meghajtómérettel (512 bájtos szektorral) a FAT16 alapértelmezés szerint létrejön, 512 MB felett - FAT32. A fürt méretét a formázás során a fájlrendszer és a kötet mérete határozza meg.
Kötet sorozatszámaA kötet sorozatszáma (a BS_VolID mező) a Windows 98 rendszerben a dátum és idő formátumából jön létre oly módon, hogy azokat további információk nélkül nem lehet visszaállítani.
A FAT kötet következő fontos szerkezete maga a FAT tábla, amely külön logikai területet foglal el. Meghatározza a kötet fájljait és mappáit tároló fürtök listáját (láncát). Egy az egyhez megfelelés van a tábla klaszterei és indexmutatói között - az N-edik mutató az azonos számú klaszternek felel meg. Az adatterület első klasztere a 2-es számot kapja. Az indexmutató értéke a megfelelő klaszter állapotának felel meg. A következő állapotok lehetségesek:
A 0 és 1 klasztereket a FAT külön tükrözi. A nulla klaszternek megfelelő indexmutató (a legelső FAT-tábla mutatója) tartalmazza a BPB_Media értékét az alsó 8 bitben; a fennmaradó bitek 1-re vannak állítva. Például, ha BPB_Media = 0xF8 (merevlemez), FAT[0] = 0x0FFFFFF8 FAT32 esetén. Így formálisan FAT[0] = EOC, amelyet nulla méretű fájlok feldolgozásakor használnak (lásd alább).
A második lefoglalt mutató, a FAT[1], formázáskor az EOC jel értékére van állítva. A FAT12-ben már nem használják, a FAT16-ban és FAT32-ben pedig ennek a mutatónak a felső két bitje tartalmazhat egy jelölést a hangerő ellenőrzésének szükségességéről (az úgynevezett „ dirty bit ”) és minden egyéb A bitek értéke 1. A szennyezett bitek jelenlétét a Windows rendszerindítási folyamata során, az autochk.exe program ellenőrzi. A piszkos bit akkor jön létre, ha a kötet nincs megfelelően leszerelve, vagy ha az adathordozón hardverhiba van, és ennek megfelelően két lehetséges értéket vesz fel.
A FAT32 indexmutató definíció szerint 32 bites, de a felső 4 bitet a rendszer figyelmen kívül hagyja, így a mutató értéke valójában 28 bit. Az egyetlen művelet, amely a mutató felső 4 bitjén működik, a kötet formázása, amely alaphelyzetbe állítja a teljes mutatót. Ez azt jelenti, hogy például a 0x10000000, 0xF0000000 és 0x00000000 mutatóértékek mind egy szabad klaszternek felelnek meg, mivel csak a felső 4 bitben különböznek.
A BPB FAT tábla mérete, azaz a BPB_FATSz16/32 értéke nagyobb lehet a valódinál, így minden FAT tábla végén lehetnek olyan szektorok, amelyek nem felelnek meg egyetlen valós adatklaszternek sem. A formázás során ezek a szektorok nullázódnak, a kötet működése közben pedig semmilyen módon nem használatosak. Ezért a FAT tábla utolsó szektorának tényleges címét, amely a valós kötet klaszterekre mutató mutatókat tartalmaz, mindig az adatterületi klaszterek teljes számából kell kiszámítani, nem pedig a BPB_FATSz16/32 mezőből. Ezenkívül a FAT tábla által elfoglalt utolsó szektort nem feltétlenül foglalja el teljesen - ebben az esetben a szektor többletterülete szintén nem kerül felhasználásra, és a kötet formázásakor nullákkal töltődik fel.
Közvetlenül az utolsó FAT-tábla vége után egy fájlokat és mappákat tartalmazó adatterület található. A FAT- könyvtár egy speciális attribútummal megjelölt normál fájl. Egy ilyen fájl adatai (tartalma) bármely FAT-verzióban 32 bájtos fájlrekordok (könyvtárrekordok) lánca. Egy könyvtár általában nem tartalmazhat két azonos nevű fájlt. Ha a lemezellenőrző program egy mesterségesen létrehozott pár azonos nevű fájlt talál ugyanabban a könyvtárban, akkor az egyiket átnevezi.
GyökérkönyvtárAz egyetlen könyvtár, amelynek jelen kell lennie, a gyökérkönyvtár. A FAT12/FAT16 rendszerben a gyökérkönyvtár szektorokban rögzített mérete van, amely a BPB_RootEntCnt értékéből kerül kiszámításra, és követi a lemezen lévő FAT táblát.
A FAT32-ben a gyökérkönyvtár, mint bármely más, változó méretű, és fürtökből álló lánc. Az első gyökérkönyvtár-fürt számát a BPB_RootClus tükrözi. A gyökérkönyvtár a következő módokon különbözik a FAT-kötet többi könyvtárától:
A FAT32 fájlrekord a következő struktúrákból áll:
Ha egy FAT bejegyzés első bájtja (azaz DIR_Name[0]) 0xE5 vagy 0x05 értéket tartalmaz, ez azt jelenti, hogy a bejegyzés szabad (a megfelelő fájlt törölték). A DIR_Name[0] nulla azt jelenti, hogy nem csak ez a bejegyzés ingyenes, hanem az összes következő címtárbejegyzés is; A Windows nem elemzi a könyvtár fennmaradó részét a nullázott bejegyzés után.
Fájlnév a FAT-banA DIR_Name mező logikailag fel van osztva az első 8 karakterre, amelyek a fájl nevét alkotják, és az utolsó 3 karakterre, amelyek a kiterjesztést alkotják. Az elválasztó periódus az operációs rendszer szintjén kerül hozzáadásra, és nem kerül tárolásra a névmezőben. Ha a fájlnév és a kiterjesztés nem tölti ki a számukra kijelölt helyet, a DIR_Name mező fennmaradó bájtjai szóközökkel (0x20) lesznek kitöltve. A fájlnév és a kiterjesztés bármilyen betű-, szám- vagy karakterkombinációt tartalmazhat 127-nél nagyobb ASCII -kóddal; A speciális karakterek három csoportra oszthatók:
A szervizkarakterek különleges jelentéssel bírnak DOS-ban és Windows-ban, és nem lehetnek részei a fájlnévnek (a * ? jelek metakarakterek , a : / \ jelek pedig elválasztóként szolgálnak a fájl elérési útjaiban , az egyéb szolgáltatási és illegális karakterek vezérlőkarakterek a parancssori értelmezőkben COMMAND. COM és cmd.exe ), míg a tiltott karakterek továbbra is szerepelhetnek a fájlnévben egy LFN-bejegyzés árán (lásd lent). Például egy ponttal kezdődő vagy több pontot tartalmazó könyvtárat létrehozhatunk parancssori módban ( mkdir .directory) vagy olyan shellekben, mint a FAR Manager , Total Commander , WinRAR . A fájlnév nem kezdődhet vagy végződhet szóközzel; A névmező egyik bájtjában sem megengedett ASCII vezérlőkarakter (azaz 0x00-0x1F), kivéve a fent megadott 5-ös kód esetét Az aktuális (a fájl létrehozásának idején) DOS kódlapra vonatkozó információ nem mentve van, így azokhoz a fájlokhoz való hozzáférés, amelyek neve tartalmazza a kiterjesztett ASCII-ből származó nemzeti kódokat (például cirill karaktereket a 866 -os kódlapról ), más kódlappal ez problémás vagy lehetetlen lehet (mert mielőtt egy fájlt keres a könyvtárban, a a név nagybetűvé alakul a kódlapon található táblázat szerint). A fájl teljes elérési útja nem haladhatja meg a 80 bájtot (3 a meghajtó betűjele; 64 az elérési út; 12 a fájl neve, beleértve a határoló pontot; 1 a terminál nulla jele).
A név minden 8,3 alfabetikus karakterét a rendszer mindig lefordítja és a DIR_Name mezőben tárolja nagybetűvel. A DIR_NTRes bájt a Windows NT név eredeti kis- és nagybetűjének megőrzésére szolgál : a 3. bitben lévő 1 azt jelzi, hogy a név kisbetűvel jelenjen meg; A kiterjesztésért a 4. bit felelős. Ha a név vagy a kiterjesztés mindkét eset karaktereit tartalmazza, akkor egy ilyen fájlhoz LFN rekord jön létre (lásd alább). A Windows 9x mindig létrehoz egy LFN bejegyzést, hogy megőrizze a név nem triviális kis- és nagybetűjét, és figyelmen kívül hagyja a DIR_NTRes mezőt. Ennek következtében előfordulhat, hogy a Windows 9x teljes egészében nagybetűvel, míg a Windows NT (részben) kisbetűvel megjeleníti ugyanannak a fájlnak a nevét, amelyhez nem tartozik LFN bejegyzés.
Fájl attribútumokAz attribútumbyte-ban a felső két bit le van foglalva, és mindig nullára kell állítani. A fennmaradó bitek úgy vannak elosztva, hogy a 0x01 érték megfeleljen a "csak olvasható" attribútumnak, 0x02 - "rejtett", 0x04 - "rendszer", 0x20 - "archivált". Az alapértékek összegzésével több attribútum halmaza készül. Ezeken a szabványos attribútumokon kívül a következőket használják: 0x10 - azt jelzi, hogy a fájl egy könyvtár (más fájlok tárolója); 0x08 - ATTR_VOLUME_ID, a gyökérkönyvtárban található egyedi nulla méretű fájl speciális attribútuma, amelynek neve kötetcímkének minősül. A 11 karakteres FAT kötetcímke korlátozás a DIR_Name mező méretéhez kapcsolódik. Ha a fájl rendelkezik a READ_ONLY | REJTETT | RENDSZER | VOLUME_ID (érték 0x0F), ez azt jelzi, hogy a bejegyzés nem egy külön fájlnak felel meg, hanem egy másik fájl hosszú nevének egy részét tartalmazza, amely nem fér bele a 8.3-as keretrendszerbe (lásd alább).
A DIR_Attr felső két bitjéhez egy nem nullától eltérő érték mesterséges hozzárendelése olyan fájlok létrehozására szolgál, amelyeket formázás nélkül nem lehet törölni vagy átnevezni a fájlrendszer szabványos eszközeivel. Ez hasznos például az Autorun.inf vírusok elleni küzdelemben (Panda USB és AutoRun Vaccine program). Másrészt maguk a vírusok is használhatják ugyanazt az eszközt. A DIR_Attr = 0x40 értéke belső használatra (eszköz) van fenntartva.
Mi történik egy könyvtár létrehozásakorA könyvtár létrehozásakor a DIR_FileSize = 0 „életre” van beállítva. Magának a könyvtárnak a méretét a fájlrendszer 65 535 32 bájtos bejegyzésre korlátozza (azaz a FAT tábla könyvtárbejegyzései nem haladhatják meg a 2 MB-ot). Ennek a korlátnak az a célja, hogy felgyorsítsa a fájlműveleteket, és lehetővé tegye különböző segédprogramok számára, hogy 16 bites egész számot (WORD) használjanak a könyvtárban lévő bejegyzések számának megszámlálásához (ennek eredményeként elméleti korlát van a könyvtárban lévő fájlok számára. - 65 535, feltéve, hogy minden fájlnév megfelel a 8.3 szabványnak). A könyvtárhoz egy adatterület-fürt van hozzárendelve (kivéve, ha az egy FAT12/FAT16 gyökérkönyvtár), és a DIR_FstClusHI / DIR_FstClusLO mezők ennek a fürtszámnak az értékére vannak beállítva. A fürthöz tartozó bejegyzéshez egy EOC-címke kerül a FAT-táblázatba, és maga a fürt nullákkal van kitöltve. Ezután két speciális fájl jön létre, amelyek nélkül a FAT-könyvtár sérültnek minősül (az első két 32 bájtos bejegyzés a fürt adatterületén) - nulla méretű "." (egy pont, könyvtárazonosító) és ".." (két pont, mutató a szülőkönyvtárra). Ezeknek a fájloknak a dátum- és időbélyegzői magának a könyvtárnak az értékére vannak beállítva a létrehozáskor, és nem frissülnek, ha a könyvtár megváltozik. A "." DIR_FstClusHI / DIR_FstClusLO mezői tartalmazza az azt tartalmazó klaszter számának értékét, és a ".." fájlt - az adott könyvtárat tartalmazó első klaszter számát. Így a fájl "." magára a könyvtárra vonatkozik, a ".." fájl pedig a szülőkönyvtár kezdeti fürtjére utal; ha a szülőkönyvtár a gyökérkönyvtár, akkor a kezdeti fürt nullának számít.
Idő és dátumA kétbájtos dátumbélyegző a következő formátumú:
A kétbájtos időbélyeg a következő formátumú:
A dátum- és időbélyegek közül csak az utolsó módosítás ideje (azaz a DIR_WrtTime és DIR_WrtDate) kritikus, a többit nem biztos, hogy sok rendszer támogatja; ha egy ilyen rendszeren lévő fájlt használ (például DOS vagy Windows 3.1 rendszerben), ezek a mezők figyelmen kívül maradnak. A FAT a helyi időzóna szerint menti a dátum- és időbélyegzőket; ha ez megváltozik, a jelek nem változnak.
A könyvtárak időbélyegei a létrehozáskor kerülnek beállításra, és nem változnak, amikor új fájlokat írnak egy könyvtárba, átneveznek vagy új fürtöt rendelnek hozzá.
A fájl utolsó hozzáférési dátuma minden alkalommal frissül, amikor hozzáfér, például a fájl tulajdonságainak megtekintésekor, amikor egy másik kötetre lép (de nem a köteten belül). Amikor másol egy fájlt Windows 98 rendszerben, az eredeti fájl utolsó hozzáférési dátuma frissül, Windows XP rendszerben azonban nem.
A fájl módosításának dátuma és ideje változik, amikor új tartalom kerül az adatterületre (nem a fájlrekordba). Más szóval, a módosítás dátuma és ideje nem változik az attribútumok megváltoztatásakor vagy a fájl átnevezésekor. A fájl áthelyezése vagy másolása megőrzi az eredeti módosítási jelet.
A létrehozás dátumát és időpontját a rendszer akkor állítja be, amikor egy fájlrekordot rendelnek hozzá egy olyan új fájlhoz, amely korábban nem létezett. Más szóval, amikor egy fájlt átneveznek vagy áthelyeznek, a létrehozás dátuma és időpontja nem változik, de másoláskor az új fájl új pecsétet kap. Így egy fájl Windows rendszeren történő másolásakor előfordulhat, hogy a létrehozás dátuma későbbi, mint a módosítás dátuma.
A hosszú nevű (8.3-nál nagyobb) fájlokat és könyvtárakat a FAT fájlrendszer speciális módon kezeli. Az LFN (Long File Name) fájl 32 bájtos rekordjának szerkezete eltér a normál (SFN) rekordtól:
A FAT-könyvtárban lévő LFN-bejegyzések készletét mindig egy normál SFN-bejegyzéshez kell társítani, amely fizikailag megelőzi a lemezt. A megfelelő normál rekord nélkül talált LFN-rekordokat árvának nevezzük , és a rekord sérültnek minősül; egy ilyen fájl teljesen láthatatlan az MS-DOS/Windows régebbi verzióiban.
Az LFN rekordok sorozatában mindegyiknek saját sorozatszáma van, amelyet az első bájt (LDIR_Ord) határoz meg. A 0x40-es maszk azt jelzi, hogy ez a bejegyzés az utolsó az utána következő LFN-bejegyzések sorában (azaz például a sor harmadik LFN-bejegyzésénél az LDIR_Ord bájt értéke 0x43, a 17.-é 0x51 ). A következő rekordokban ez a bájt N-ről a fiók N-edik "hosszú" rekordja esetén a megfelelő normál értékről 1-re változik a normál rekordhoz legközelebbinél.
A hosszú fájlnevek Unicode ( UTF-16 ) kódolással kerülnek tárolásra , megőrizve a beírt alfabetikus karakterek kis- és nagybetűit. Ha egy bizonyos OEM- vagy Unicode-névkarakter nem konvertálható kódlapkarakterré, az mindig aláhúzásjelként „_” jelenik meg, és a lemezen tárolt tényleges karakter nem változik.
Az ellenőrző összeg bájtját egy bizonyos algoritmus szerint számítják ki egy normál rekord 8.3-as neve alapján (hosszú névvel rendelkező fájl esetén a szokásos rekordból származó "nevet" aliasnak - aliasnak nevezik), és átmásolják az összes "hosszú" fájlba. " megfelelő rekordok. Ha valamelyik érték nem egyeztethető össze a fájlnévvel (például ha a fájlt az MS-DOS/Windows korai verziójában nevezték át), akkor egy árva fájl lép fel.
A hosszú névvel rendelkező SFN-fájl álnév egy törzsből és szükség esetén egy digitális "farokból" áll. Ha a fájl kiterjesztéssel rendelkezik, az első három karakter az álnévben kerül tárolásra. A megfelelő név úgy jön létre, hogy a hosszú fájlnév karaktereit lefordítják az OEM kódolásba, a hosszú név minden szóközét figyelmen kívül hagyva, és az OEM-ben nem lefordítható vagy a rövid név kontextusában tiltott karaktereket helyettesítik egy aláhúzás "_". A "~n" számjegy farka, ahol n = 1 ÷ 999999, hozzáadódik az álnévhez, ha az eredetileg kapott álnév ütközött bármely fájl nevével ugyanabban a könyvtárban, vagy hosszabb volt, mint a 8.3 szabvány meghatározza, vagy ha bármilyen karakter A változó kódolás nem talált OEM megfelelőt, és aláhúzás váltotta fel. Így olyan álnevek jönnek létre, mint a NEWFIL~1.DJV (LFN = New file for me.djvu). A fájl álnevezési séma a sebességre van optimalizálva, ezért részleteiben kiszámíthatatlan.
Az a fájlnév, amely nem többszöröse 13 karakterből, nem tölti ki teljesen a FAT-tábla LFN-bejegyzéseinek névmezőit. Ebben az esetben a fájlnév mesterségesen NUL karakterrel (0x00) van lezárva, és a felesleges bájtokat egyesek (azaz 0xFF karakterek) tömítik el.
Hosszú nevek esetén a név hossza 255 karakterre korlátozódik, a NUL elválasztót nem számítva, a teljes elérési út pedig 260 karakterre korlátozódik, beleértve a NUL-t is. A hosszú név hat speciális karakter használatát is lehetővé teszi, amelyek tilosak a rövid nevekben: +,; =[]
Ha egy FAT32-köteten egy ilyen karaktert tartalmazó fájlt vagy könyvtárat próbál létrehozni, akkor a fájlnév hosszától függetlenül automatikusan létrejön egy LFN bejegyzés. Hasonló folyamat megy végbe, amikor nem ASCII karaktereket tartalmazó fájlt/mappát hoz létre.
Előfordulhat, hogy a kötetcímkefájl fizikailag nem előzi meg a kötetben lévő összes bejegyzést hosszú névvel (ha a kötetnek nincs címkéje, vagy a címke egy hosszú nevű fájl írása után lett hozzárendelve). Ekkor a kötetcímke a FAT12/FAT16-ban nem jelenik meg megfelelően, mivel a legközelebbi LFN rekordból lesz levéve (mert az is rendelkezik a VOLUME_ID attribútummal), és ha megpróbálja megváltoztatni a kötetcímkét, akkor a megfelelő fájl neve ténylegesen megsértik. Az LFN-rekordokat tartalmazó fájl törlése nem érinti az utóbbiakat, és árvává válnak. Az új fájl további létrehozása során az említett árva hibásan társítható hozzá, ha a régi és az új fájlok nevének ellenőrző összege megegyezik, azonban az alkalmazott ellenőrzőösszeg-számítási algoritmussal (a fájl első karakterének ASCII kódja az alias ciklikusan eltolódik egy kicsit jobbra, és hozzáadódik a következő karakter kódja stb. d) elhanyagolhatóvá teszi ezt a valószínűséget.
Kötet formázás - az indexmutató táblázat nullára áll, kivéve az első három esetet (a FAT[0] és a FAT[1] le van foglalva, és a FAT[2] a kötetcímkefájlnak megfelelő bejegyzést tartalmaz, vagy ha az hiányzik az EOC címke) és a sérült klaszterek nyilvántartása; a gyökérkönyvtár bejegyzései nullára vannak állítva (kivéve a kötetcímke fájlt, ha van ilyen), különben az adatterületet ez nem érinti.
Fájl törlése – a fájlrekord és az összes kapcsolódó LFN rekord első karakterét a 0xE5 kód váltja fel; a fájl által elfoglalt fürtök szabadként vannak megjelölve a FAT táblában, de az adatterület fürtjeit ez nem érinti.
Fájl vagy könyvtár létrehozása a helyi menü "Új" parancsával - egy fájl bejegyzés jön létre egy új "üres" fájlhoz alapértelmezett névvel (például "Új mappa") és a fájltípus által meghatározott mérettel; maga a fájl, ha mérete nem nulla (ami szinte minden "üres" fájlra igaz, kivéve a könyvtárakat és a szöveges dokumentumokat), a hozzá rendelt fürtök adatterületére íródik; a megfelelő fürtlánc létrejön a FAT táblában. A fájl érvényes (nem alapértelmezett) név megadása után az eredetileg létrehozott fájl bejegyzés töröltként lesz megjelölve, és létrejön egy új.
Fájl átnevezése - új bejegyzés jön létre frissített névvel; a régi bejegyzés töröltként van megjelölve.
Fájl mentése az alkalmazásból (nem a parancssorból) - létrejön egy rekord, amely az összes mezőt tartalmazza, kivéve a fájl méretét és kezdeti fürtjét; a fájl mentése után az összes mezőt tartalmazó új rekord jön létre, és a régi rekord törlődik.
Fájl másolása - az új helyen egy azonos fájlrekord jön létre (talán néhány időbélyeg kivételével, lásd fent), az első szabad fürt hozzá van rendelve a fájlhoz, és a fájl tartalma átmásolódik az új helyre, miközben a aktuális klaszter, megkeresi a következő szabad fürtöt és kitölti a FAT táblát .
Fájl áthelyezése (különböző kötetek között) - a fájl másolása, majd törlése az eredeti helyéről.
Fájlok áthelyezése (a köteten belül) - a fürtlánc nem érinti, a fájlrekord változatlan formában átmásolódik az új könyvtárba, majd törlődik a régiből.
A szabad fürt keresése az indexmutatók táblázatában egy új fájlhoz való hozzárendeléshez általában nem az adatterület elejétől (vagyis a 2-es fürttől), hanem a fájlhoz utoljára hozzárendelt fürttől kezdődik, a amelyet az FSIinfo struktúrában tárolunk. Más szavakkal, ha az 1-es fájlhoz a 30-as fürthöz, a 2-höz pedig a 31-es fürthöz volt hozzárendelve, majd az 1-es fájlt törölték, akkor az új 3-as fájl létrehozásakor nagy valószínűséggel a 32-es fürttől kezdve fizikailag is megtalálható lesz.
Mivel a FAT rendszer ugyanabban a táblában tárolja a fájlokról és a szabad lemezterületről szóló adatokat, ezért a fájlírási művelet, amely hagyományosan két szakaszból áll (a foglalt blokk hozzáadása a foglaltak listájához és ugyanazon blokk törlése a ingyenesek), a FAT-ban egy műveletben fordul elő. Emiatt a FAT-rendszer eredendő hibatűréssel rendelkezik, vagyis az olvasási vagy írási művelet során fellépő hiba (például tápfeszültség) a legtöbb esetben nem vezet a fájlrendszer tönkremeneteléhez. Ebben az esetben azonban a fájlrendszer integritásáról beszélünk, és nem magukról a fájlokról.
| FAT12 | FAT16 | FAT32 | |
|---|---|---|---|
| Fejlesztő | Microsoft | ||
| Teljes cím | Fájlkiosztási táblázat | ||
| (12 bites verzió) | (16 bites verzió) | (32 bites verzió) | |
| Bemutatták | 1980 ( Microsoft Disk BASIC ) | 1984. augusztus ( MS-DOS 3.00, csonka) teljes - 1988. július, MS-DOS 4.0 [6] |
1996. augusztus (Windows 95 OSR 2) |
| Kötetazonosító | 0x01 ( MBR ) | 0x04, 0x06, 0x0E (MBR) | 0x0B, 0x0C (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT ) |
| szerkezetek | |||
| Címtár tartalma | asztal | ||
| Fájl elhelyezése | Lineáris lista | ||
| Rossz blokkok | Klaszter címkézés | ||
| Korlátozások | |||
| fájl méret | 32 MB_ | 2 GB_ | 4 GB |
| Klaszterek száma | 4084 | 65 524 | 268 435 445 (2 28-12 ) |
| A fájlnév hossza | 8,3 vagy 255 karakter LFN használata esetén | ||
| Kötet mérete | 2 MB (512 bájt szektoronként)
32 MB (64 KB fürtönként) |
2 GB 4 GB (64 KB fürtönként, nem mindenhol támogatott) |
2 TB 8 TB (32 KB szektoronként) |
| Képességek | |||
| Tárolt dátumok | Létrehozás, módosítás, hozzáférés | ||
| Időintervallum | 1980. január 1. – 2107. december 31 | ||
| További információ | Kezdetben nem támogatott | ||
| Fájl attribútumok | Csak olvasható, rejtett, rendszer-, kötetcímke, alkönyvtár, archívum | ||
| A hozzáférési jogok differenciálása | Nem | ||
| Átlátszó tömörítés | Önálló segédprogramok ( Stacker , DoubleSpace , DriveSpace ) | ||
| Átlátszó titkosítás | Harmadik féltől származó segédprogramok vagy DOS-klónok | ||
A FAT-tal és VFAT-tal való munkavégzéshez szükséges egyes algoritmusokat a Microsoft szabadalmaztatta.
Az USA-ban újragondolás alatt[ mikor? ] egyes szabadalmak törléséről döntöttek, de aztán törölték.
2006 októberében az Európai Szabadalmi Hivatal [7] VFAT szabadalmát nyilvánvaló okokból törölték Németországban .
Idővel a FAT-ot széles körben használták különféle eszközökben a DOS, Windows, OS / 2 és Linux közötti kompatibilitás érdekében. A Microsoft nem mutatott szándékot arra, hogy engedélyre kényszerítse őket[ pontosítás ] [8] .
2009 februárjában a Microsoft beperelte a TomTomot , a Linux -alapú autós navigációs rendszereket gyártó céget szabadalombitorlás miatt [9] .
Jeremy Ellison szerint[ pontosítás ] A Microsoft célja, hogy választási lehetőség elé állítsa a különböző cégeket: szabadalmi oltalmi megállapodást kössenek a Microsofttal (mint például a Novell 2006 novemberében), ezzel megsértve a GNU GPL-t, és ellehetetlenítve a Linux használatát. , vagy ne kössön ilyen megállapodást, és olyan szabadalmak megsértésével vádolják, amelyek védelmét a megkötésekor a nyilvánosságra hozatal elmulasztása mellett biztosítják [10] [11] .
2009 márciusában a TomTom viszontkeresetet nyújtott be szabadalombitorlás miatt [12] .
| OS/2 összetevők és API -k | |
|---|---|
| Fő | |
Menedzsment szolgáltatások | |
| Játékok |
|
| OS kernel | |
| Fájlrendszerek | |
| Grafikai alrendszer |
|
| Objektummodell | SOM
|
| Kompatibilitás |
|
| Fájlrendszerek ( lista , összehasonlítás ) | |||||||
|---|---|---|---|---|---|---|---|
| Korong |
| ||||||
| Elosztott (hálózat) | |||||||
| Különleges |
| ||||||
| Ecma nemzetközi szabványok | |
|---|---|