FETT

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 18 juni 2022; kontroller kräver 2 redigeringar .

FAT ( engelsk  File Allocation Table "filallokeringstabell") är en klassisk filsystemsarkitektur , som på grund av sin enkelhet fortfarande används i stor utsträckning för flash-enheter . Används i disketter , minneskort och vissa andra lagringsmedia. Tidigare användes den även på hårddiskar.

Utvecklad av Bill Gates och Mark McDonald 1976-1977 [1] [2] . Det användes som huvudfilsystem i operativsystem i MS-DOS- och Windows 9x -familjerna .

FAT-strukturen följer ECMA-107-standarden och definieras i detalj av den officiella Microsoft-specifikationen känd som FATGEN [3] .

Versioner av FAT-systemet

Det finns fyra versioner av FAT - FAT12 , FAT16 , FAT32 och exFAT (FAT64) . De skiljer sig i bitheten för poster i skivstrukturen, det vill säga antalet bitar som är reserverade för att lagra klusternumret. FAT12 används främst för disketter , FAT16 för små diskar. Baserat på FAT utvecklades ett nytt exFAT (extended FAT) filsystem, som främst används för flash-enheter .

Från början stödde inte FAT ett hierarkiskt katalogsystem - alla filer fanns i roten på disken. Detta gjordes för enkelhetens skull, eftersom det på enkelsidiga disketter med en kapacitet på endast 160–180 KB helt enkelt inte var meningsfullt att sortera några filer i kataloger. Med spridningen av disketter på 320 eller fler kilobyte visade det sig att det var obekvämt att lagra alla filer i roten, dessutom begränsade den lilla storleken på rotkatalogen antalet filer på disken. Kataloger introducerades med lanseringen av MS-DOS 2.0.

Olika operativsystem har också implementerat olika FAT-tillägg. Till exempel har DR-DOS ytterligare filåtkomstattribut; i Windows 95 , Linux  - stöd för långa filnamn (LFN) i Unicode-format (Virtual FAT - VFAT); på OS/2  utökade attribut för alla filer.

VFAT

VFAT  är en FAT-tillägg som introduceras i Windows 95 . I FAT är filnamn i 8.3 -format och består endast av ASCII-tecken . Stöd för långa (upp till 255 tecken) filnamn ( Långt filnamn, LFN ) i UTF-16LE- kodning lades till i VFAT ,  medan LFN lagras samtidigt med namn i 8.3-format, i efterhand kallat SFN ( Engelska korta filnamn ). LFN:er är skiftlägesokänsliga när de slås upp, men till skillnad från SFN:er, som lagras med versaler, behåller LFN:er det skiftläge som angavs när filen skapades [4] [5] .  

Struktur för FAT-systemet

I FAT-filsystemet kombineras sammanhängande skivsektorer till enheter som kallas kluster . Antalet sektorer i ett kluster är lika med en potens av två (se nedan). Ett heltal av kluster (minst ett) tilldelas för att lagra fildata, så om till exempel filstorleken är 40 byte och klusterstorleken är 4 KB, kommer endast 1 % av utrymmet som tilldelats för det att vara upptas av filinformationen. För att undvika sådana situationer är det tillrådligt att minska storleken på klustren och vice versa för att minska mängden adressinformation och öka hastigheten på filoperationer. I praktiken väljs en viss kompromiss. Eftersom diskkapaciteten mycket väl inte kan uttryckas i ett heltal av kluster, finns det vanligtvis i slutet av volymen så kallade överskottssektorer - en "återstod" mindre än ett kluster i storlek, som inte kan allokeras av OS för lagra information.

FAT32-volymutrymmet är logiskt uppdelat i tre sammanhängande områden:

FAT12 och FAT16 har också ett dedikerat område för rotkatalogen. Den har en fast position (direkt efter det sista elementet i FAT-tabellen) och en fast storlek i 32-byte-element, det vill säga när man beskriver i Partition Boot Record, är det exakt antalet 32-byte-element som anges , som var och en beskriver alla element i rotkatalogen (vare sig det är fil eller annan underkatalog).

Om ett kluster tillhör en fil, innehåller motsvarande cell i FAT-tabellen numret på nästa kluster i samma fil. Om cellen motsvarar det sista klustret i filen, så innehåller den ett speciellt värde (0xFFFF för FAT16). Således byggs en kedja av filkluster. Nollor motsvarar oanvända kluster i tabellen. "Dåliga" kluster (som är exkluderade från bearbetning, till exempel eftersom motsvarande område på enheten är oläsligt) har också en speciell kod (0xFFF7 för FAT16).

När en fil raderas ersätts det första tecknet i namnet med specialkoden 0xE5 och filens klusterkedja i allokeringstabellen nollställs. Eftersom informationen om filstorleken (som finns i katalogen bredvid filnamnet) förblir intakt, kan den raderade filen återställas om filklustren placerades sekventiellt på disken och inte skrevs över med ny information.

Boot record

Den första strukturen för en FAT-volym kallas BPB ( BIOS  parameter block ) och är belägen i ett reserverat område, i sektor noll. Denna struktur innehåller information som identifierar typen av filsystem och mediets fysiska egenskaper (diskett eller hårddiskpartition).

BIOS Parameter Block (BPB)

BPB var frånvarande från FAT, som tjänade MS-DOS 1.x, eftersom det vid den tiden endast antogs två olika typer av volymer - enkelsidiga och dubbelsidiga fem-tums 320 KB disketter, och volymformatet bestämdes av den första byten i FAT-området. BPB introducerades i MS-DOS 2.x i början av 1983 som en obligatorisk uppstartssektorstruktur för att bestämma volymformatet hädanefter; det gamla FAT first byte-detekteringsschemat stöddes inte längre. Även i MS-DOS 2.0 introducerades en hierarki av filer och mappar (innan dess lagrades alla filer i rotkatalogen).

BPB-strukturen i MS-DOS 2.x innehöll ett 16-bitars "totalt antal sektorer"-fält, vilket innebar att denna version av FAT var fundamentalt otillämplig för volymer större än 2 16 = 65 536 sektorer, det vill säga mer än 32 MB med en standardsektorstorlek på 512 byte. I MS-DOS 4.0 (1988) utökades BPB-fältet till 32 bitar, vilket innebar en ökning av den teoretiska volymstorleken till 232 = 4 294 967 296 sektorer, dvs upp till 2 TB med en 512-byte sektor.

Nästa modifiering av BPB dök upp med Windows 95 OSR2, som introducerade FAT32 (i augusti 1996). Gränsen på 2 TB för volymstorlek har tagits bort, en FAT32-volym kan teoretiskt vara upp till 8 TB stor. Storleken på varje enskild fil får dock inte överstiga 4 GB. BIOS-parameterblocket i FAT32, för kompatibilitet med tidigare versioner av FAT, upprepar BPB för FAT16 till och med BPB_TotSec32-fältet, följt av skillnader.

FAT32 "startsektorn" är faktiskt tre 512-byte sektorer - sektorerna 0, 1 och 2. Var och en av dem innehåller signaturen 0xAA55 på adressen 0x1FE, det vill säga i de två sista byte, om sektorstorleken är 512 byte. Om sektorstorleken är mer än 512 byte, så finns signaturen både på adressen 0x1FE och i de sista två byten av nollsektorn, det vill säga den dupliceras.

FSInfo

Startposten för en FAT32-partition innehåller en struktur som kallas FSInfo som används för att lagra värdet på volymens fria klusterantal. FSInfo upptar som regel sektor 1 (se fältet BPB_FSInfo) och har följande struktur (adresser i förhållande till början av sektorn):

  • FSI_LeadSig. 4-bytesignaturen 0x41615252 indikerar att sektorn används för FSInfo-strukturen.
  • FSI_Reserved1. Intervallet från 4 till 483 byte för sektorn, inklusive, återställs till noll.
  • FSI_StrucSig. En annan signatur finns på 0x1E4 och innehåller värdet 0x61417272.
  • FSI_Free_Count. 4-byte-fältet på adress 0x1E8 innehåller det sista antalet lediga kluster på volymen som systemet känner till. Värdet 0xFFFFFFFF betyder att antalet fria kluster är okänt och måste beräknas.
  • FSI_Nxt_Free. 4-byte-fältet på adress 0x1EC innehåller klusternumret från vilket sökningen efter lediga kluster i indexpekartabellen ska börja. Vanligtvis innehåller detta fält numret på det sista FAT-klustret som tilldelats för fillagring. Värdet 0xFFFFFFFF betyder att sökningen efter ett ledigt kluster bör utföras från början av FAT-tabellen, det vill säga från det andra klustret.
  • FSI_Reserved2. Reserverat 12-byte-fält på adress 0x1F0.
  • FSI_TrailSig. Signaturen 0xAA550000 är de sista 4 byten i FSInfo-sektorn.

Poängen med att introducera FSInfo är att optimera driften av systemet, eftersom indexpekartabellen i FAT32 kan vara mycket stor och dess byte-för-byte-sökning kan ta avsevärd tid. Värdena för fälten FSI_Free_Count och FSI_Nxt_Free kanske inte stämmer överens med verkligheten och bör kontrolleras för tillräcklighet. Dessutom uppdateras de inte ens i FSInfo-säkerhetskopian, som vanligtvis finns i sektor 7.

Bestämma typen av FAT-volym

Att bestämma FAT-typen för en volym (det vill säga valet mellan FAT12, FAT16 och FAT32) görs av operativsystemet baserat på antalet kluster i volymen, vilket i sin tur bestäms från BPB-fälten. Först och främst beräknas antalet sektorer i rotkatalogen:

RootDirSectors = (BPB_RootEntCnt * 32) / BPB_BytsPerSec

Därefter bestäms vilka av fälten BPB_FATSz16/32 och BPB_TotSec16/32 som inte är lika med noll, och de används för att bestämma antalet sektorer i volymdataområdet:

DataSec = TotSec - (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) + RootDirSectors)

Slutligen bestäms antalet dataområdeskluster:

CountofClusters = DataSec / BPB_SecPerClus

Med antalet kluster finns det en en-till-en-korrespondens med filsystemet:

  • Antal kluster < 4085 - FAT12
  • Antal kluster = 4085 ÷ 65524 - FAT16
  • Antal kluster > 65524 - FAT32

Enligt den officiella specifikationen är detta det enda giltiga sättet att bestämma FAT-typen. Att på konstgjord väg skapa en volym som bryter mot de angivna mappningsreglerna kommer att göra att den hanteras felaktigt av Windows. Det rekommenderas dock att undvika värden för CountofClusters som ligger nära de kritiska värdena (4085 och 65525) för att korrekt bestämma filsystemstypen av eventuella, ofta felaktigt skrivna, drivrutiner.

FAT12 skapas alltid på en diskett när det formateras . När det gäller hårddiskar och flashenheter , då med en enhetsstorlek på upp till 512 MB (med en 512-byte sektor), skapas FAT16 som standard, över 512 MB - FAT32. Klusterstorleken bestäms under formateringen baserat på filsystemet och volymstorleken.

Volymens serienummer

Volymens serienummer (fältet BS_VolID) i Windows 98 skapas från formatet datum och tid på ett sådant sätt att det är omöjligt att återställa dem utan ytterligare information.

FAT-tabell

Nästa viktiga struktur för en FAT-volym är själva FAT-tabellen, som upptar ett separat logiskt område. Den definierar en lista (kedja) med kluster som är värd för volymens filer och mappar. Det finns en en-till-en-överensstämmelse mellan kluster och indexpekare i tabellen - den N:te pekaren motsvarar klustret med samma nummer. Det första klustret i dataområdet tilldelas numret 2. Indexpekarens värde motsvarar tillståndet för motsvarande kluster. Följande tillstånd är möjliga:

  • klustret är fritt — pekaren är nollställd;
  • klustret är upptaget av en fil och är inte det sista filklustret — pekaren innehåller numret på nästa filkluster;
  • klustret är det sista klustret i filen — pekaren innehåller etiketten EOC (End Of Clusterchain), vars värde beror på FAT-versionen: för FAT12 är EOC-etiketten valfritt värde större än eller lika med 0x0FF8 (0x0FFF av standard); för FAT16 — större än eller lika med 0xFFF8 (standard 0xFFFF); för FAT32, alla värden större än eller lika med 0x0FFFFFF8 (0x0FFFFFFF som standard);
  • klustret är skadat — pekaren innehåller en speciell etikett, vars värde är 0x0FF7 för FAT12, 0xFFF7 för FAT16 och 0x0FFFFFF7 för FAT32. Ett skadat kluster kan inte användas av filsystemet för datalagring; motsvarande pekare påverkas inte vid formatering av volymen, när alla andra pekare är nollställda;
  • klustret är reserverat "för framtida standardisering" - pekaren innehåller ett värde som är större än CountofClusters, men mindre än etiketten för det skadade klustret (det vill säga upp till och inklusive 0xFFF6 för FAT16). I det här fallet anses klustret, som inte motsvarar några riktiga data, vara upptaget och hoppas över när man söker efter ett ledigt, men ingen annan information om det tillhandahålls.

Kluster 0 och 1 reflekteras separat av FAT. Indexpekaren som motsvarar kluster noll (den allra första FAT-tabellpekaren) innehåller värdet för BPB_Media i de lägre 8 bitarna; de återstående bitarna sätts till 1. Till exempel, om BPB_Media = 0xF8 (hårddisk), FAT[0] = 0x0FFFFFF8 för FAT32. Således formellt FAT[0] = EOC, som används vid bearbetning av nollstorleksfiler (se nedan).

Den andra reserverade pekaren, FAT[1], är inställd på värdet för EOC-märket vid formatering. I FAT12 används den inte längre på något sätt, och i FAT16 och FAT32 kan de två övre bitarna av denna pekare innehålla en markering om behovet av att kontrollera volymen (den så kallade " smutsiga biten ") och alla andra bitar är inställda på 1. Förekomsten av en smutsig bit kontrolleras under Windows-startprocessen autochk.exe-programmet. Den smutsiga biten genereras när volymen inte är ordentligt demonterad eller när mediet har ett hårdvarufel och därför tar två möjliga värden.

En FAT32-indexpekare är per definition 32 bitar, men de 4 översta bitarna ignoreras faktiskt, så värdet på pekaren är i själva verket 28 bitar. Den enda operationen som fungerar på de fyra översta bitarna av pekaren är volymformatering, som återställer hela pekaren. Det betyder att till exempel pekarvärdena 0x10000000, 0xF0000000 och 0x00000000 alla motsvarar ett fritt kluster, eftersom de bara skiljer sig i de 4 översta bitarna.

Värdet på BPB FAT-tabellstorleken, dvs BPB_FATSz16/32, kan vara större än den verkliga, så att det kan finnas sektorer i slutet av varje FAT-tabell som inte motsvarar några riktiga datakluster. Under formatering återställs dessa sektorer till noll, och under driften av volymen används de inte på något sätt. Därför måste den faktiska adressen för den sista sektorn i FAT-tabellen, som innehåller pekare till verkliga volymkluster, alltid beräknas från det totala antalet dataområdeskluster och inte från BPB_FATSz16/32-fältet. Dessutom är den sista sektorn som upptas av FAT-tabellen inte nödvändigtvis helt upptagen av den - i det här fallet används inte heller sektorns överskottsutrymme och fylls med nollor när volymen formateras.

Filposter

Omedelbart efter slutet av den sista FAT-tabellen finns ett dataområde som innehåller filer och mappar. En FAT- katalog är en vanlig fil märkt med ett speciellt attribut. Data (innehåll) i en sådan fil i valfri FAT-version är en kedja av 32-byte filposter (katalogposter). En katalog kan normalt inte innehålla två filer med samma namn. Om kontrolldiskprogrammet hittar ett artificiellt skapat par med identiskt namngivna filer i samma katalog, byts en av dem om.

Rotkatalog

Den enda katalogen som måste finnas är rotkatalogen. I FAT12/FAT16 har rotkatalogen en fast storlek i sektorer, som beräknas från värdet på BPB_RootEntCnt, och följer FAT-tabellen på disken.

I FAT32 har rotkatalogen, precis som alla andra, en variabel storlek och är en kedja av kluster. Numret på det första rotkatalogklustret återspeglas av BPB_RootClus. Rotkatalogen skiljer sig från andra kataloger på en FAT-volym på följande sätt:

  • den har inga datum- och tidsstämplar;
  • inget eget namn (förutom "\");
  • den innehåller inte filer med namnet "." och ".." (se nedan);
  • är den enda katalogen som normalt kan innehålla en volymetikettfil (se nedan).
Struktur för en filpost

En FAT32-filpost består av följande strukturer:

  • DIR_Name. 11-byte-fältet vid relativ adress 0 innehåller det korta filnamnet (under 8.3-standarden). Se nedan för filnamn.
  • DIR_Attr. Byte på adress 0x0B, ansvarig för filattribut.
  • DIR_NTRes. Byte på adress 0x0C, används i Windows NT.
  • DIR_CrtTimeTenth. Byte på adress 0x0D. Antalet tiotals millisekunders filskapande tid, giltiga värden är 0–199. Fältet ignoreras ofta i onödan.
  • DIR_CrtTime. 2 byte vid adress 0x0E. Filskapande tid exakt till 2 sekunder.
  • DIR_CrtDate. 2 byte på adress 0x10. Datumet då filen skapades.
  • DIR_LstAccDate. 2 byte på adress 0x12. Datumet för den senaste åtkomsten till filen (det vill säga den senaste läsningen eller skrivningen - i det senare fallet är det lika med DIR_WrtDate). Det finns inget liknande fält för tid.
  • DIR_FstClusHI. 2 byte på adress 0x14. Filens första klusternummer (högt ord, noll på en FAT12/FAT16-volym).
  • DIR_WrtTime. 2 byte på adress 0x16. Tidpunkten för den senaste inspelningen (ändringen) av filen, till exempel dess skapande.
  • DIR_WrtDate. 2 byte på adress 0x18. Datumet för den senaste inspelningen (ändringen) av filen, inklusive skapande.
  • DIR_FstClusLO. 2 byte vid adress 0x1A. Numret på det första klustret i filen (lågt ord).
  • DIR_Filstorlek. DWORD som innehåller värdet på filstorleken i byte. Den grundläggande begränsningen för FAT32 är att den maximalt tillåtna filstorleken är 0xFFFFFFFF (det vill säga 4 GB minus 1 byte).

Om den första byten i en FAT-post (det vill säga DIR_Name[0]) innehåller 0xE5 eller 0x05, betyder det att posten är ledig (motsvarande fil har tagits bort). Noll i DIR_Name[0] betyder att inte bara denna post är gratis, utan även alla efterföljande katalogposter; Windows analyserar inte resten av en katalog efter en nollställd post.

Filnamn i FAT

Fältet DIR_Name är logiskt uppdelat i de första 8 tecknen, som bildar filnamnet, och de sista 3, som utgör tillägget. Separatorperioden läggs till på operativsystemnivå och lagras inte i namnfältet. Om filnamnet och filtillägget inte fyller utrymmet som är tilldelat för dem, fylls de återstående byten i fältet DIR_Name med mellanslag (0x20). Filnamnet och filtillägget kan innehålla valfri kombination av bokstäver, siffror eller tecken med ASCII- koder större än 127; specialtecken är indelade i tre grupper:

  • Tillåtet: ! # $ % & () - @ ^ _ ` { } ~ '
  • Förbjudet: +.; =[]
  • Service: * ? <: > / \ | "

Servicetecken har en speciell betydelse i DOS och Windows och kan inte vara en del av ett filnamn (tecken * ? är metatecken och tecken : / \ används som avgränsare i filsökvägar , andra tjänste- och illegala tecken är kontrolltecken i kommandoradstolkare COMMAND. COM och cmd.exe ), medan förbjudna tecken fortfarande kan inkluderas i filnamnet till priset av en LFN-post (se nedan). Till exempel kan en katalog med ett namn som börjar med en punkt eller som innehåller flera punkter skapas i kommandoradsläge ( mkdir .directory) eller i skal som FAR Manager , Total Commander , WinRAR . Filnamnet kan inte börja eller sluta med ett mellanslag; inga ASCII-kontrolltecken (det vill säga 0x00-0x1F) är tillåtna i någon byte i namnfältet, förutom fallet med kod 5 som anges ovan. Information om den aktuella (vid den tidpunkt då filen skapades) DOS -teckentabell är inte sparas, så tillgång till filer vars namn innehåller nationella koder från Extended ASCII (till exempel kyrilliska tecken från teckentabell 866 ), med en annan teckentabell, kan det vara problematiskt eller omöjligt (eftersom innan du söker efter en fil i katalogen, dess namn konverteras till versaler i enlighet med tabellen i teckentabellen). Den fullständiga sökvägen till filen får inte överstiga 80 byte (3 är enhetsbeteckningen; 64 är sökvägen; 12 är filnamnet, inklusive avgränsningspunkten; 1 är terminalens nolltecken).

Alla 8,3 alfabetiska tecken i namnet översätts alltid och lagras i fältet DIR_Name med versaler. DIR_NTRes-byten används för att bevara det ursprungliga skiftläget för ett Windows NT -namn: en 1 i bit 3 talar om för att namnet ska visas med gemener; För tillägget ansvarar bit 4. Om namnet eller tillägget innehåller tecken från båda fallen skapas en LFN-post för en sådan fil (se nedan). Windows 9x skapar alltid en LFN-post för att bevara namnets icke-triviala skiftläge och ignorerar fältet DIR_NTRes. Som en konsekvens kan namnet på samma fil, utan en associerad LFN-post, visas av Windows 9x helt med versaler, men Windows NT (delvis) med gemener.

Filattribut

I attributbyten är de två översta bitarna reserverade och måste alltid sättas till noll. De återstående bitarna fördelas på ett sådant sätt att värdet 0x01 motsvarar "read-only" attributet, 0x02 - "hidden", 0x04 - "system", 0x20 - "archived". En uppsättning av flera attribut görs genom att summera de grundläggande värdena. Utöver dessa standardattribut används följande: 0x10 - indikerar att filen är en katalog (behållare för andra filer); 0x08 - ATTR_VOLUME_ID, ett speciellt attribut för en unik nollfil i rotkatalogen, vars namn anses vara en volymetikett. Den 11 tecken långa FAT-volymetiketten är relaterad till storleken på fältet DIR_Name. Om filen har READ_ONLY | DOLDA | SYSTEM | VOLUME_ID (värde 0x0F), detta indikerar att posten inte motsvarar en separat fil, utan innehåller en del av ett långt namn på en annan fil som inte passar in i 8.3-ramverket (se nedan).

En artificiell tilldelning av ett värde som inte är noll till de två övre bitarna av DIR_Attr används för att skapa filer som inte kan tas bort eller byta namn på standardmedel i filsystemet utan formatering. Detta är användbart, till exempel när du bekämpar Autorun.inf-virus (Panda USB och AutoRun Vaccine-programmet). Å andra sidan kan virus själva använda samma verktyg. Värdet på DIR_Attr = 0x40 är reserverat för internt bruk (enhet).

Vad händer när en katalog skapas

När en katalog skapas ställs DIR_FileSize = 0 för den "för livet" Storleken på kataloginnehållet bestäms genom att helt enkelt följa kedjorna av kluster upp till End Of Chain-märket. Storleken på själva katalogen begränsas av filsystemet till 65 535 32-byte-poster (det vill säga katalogposter i FAT-tabellen får inte överstiga 2 MB). Denna gräns är avsedd att påskynda filoperationer och tillåta olika verktyg att använda ett 16-bitars heltal (WORD) för att räkna antalet poster i en katalog (som ett resultat finns det en teoretisk gräns för antalet filer i en katalog - 65 535, förutsatt att alla filnamn följer standarden 8.3). Katalogen tilldelas ett dataområdeskluster (såvida det inte är en FAT12/FAT16 rotkatalog), och fälten DIR_FstClusHI / DIR_FstClusLO är inställda på värdet för det klusternumret. En EOC-etikett placeras i FAT-tabellen för posten som motsvarar detta kluster, och själva klustret fylls med nollor. Därefter skapas två specialfiler, utan vilka FAT-katalogen anses vara skadad (de första två 32-byte-posterna i klusterdataområdet) - nollstorleksfiler med namnen "." (en punkt, katalogidentifierare) och ".." (två punkter, pekare till den överordnade katalogen). Datum- och tidsstämplarna för dessa filer är inställda på värdena för själva katalogen vid tidpunkten för skapandet och uppdateras inte när katalogen ändras. Fälten DIR_FstClusHI / DIR_FstClusLO i "." innehålla värdet på numret på klustret som innehåller det, och filen ".." - numret på det första klustret i katalogen som innehåller det givna. Alltså filen "." hänvisar till själva katalogen, och filen ".." hänvisar till det ursprungliga klustret i den överordnade katalogen; om den överordnade katalogen är rotkatalogen, anses det initiala klustret vara noll.

Tid och datum

En tvåbyte datumstämpel har följande format:

  • bitar 0-4 — dag i månaden, värden 1-31 är tillåtna;
  • bitar 5–8 — månad på året, värden 1–12 är tillåtna;
  • bitar 9-15 - år, räknat från 1980 ("MS-DOS-epok"), värden från 0 till 127 inklusive är möjliga, det vill säga 1980-2107.

En tidsstämpel på två byte har följande format:

  • bitar 0-4 - sekunderräknare (två vardera), giltiga värden är 0-29, det vill säga 0-58 sekunder;
  • bitar 5-10 är minuter, giltiga värden är 0-59;
  • bitar 11-15 är timmar, giltiga värden är 0-23.

Av datum- och tidsstämplarna är endast den senaste ändringstiden (det vill säga DIR_WrtTime och DIR_WrtDate) kritisk, resten kanske inte stöds av många system; när du använder en fil på ett sådant system (till exempel i DOS eller Windows 3.1), ignoreras dessa fält. FAT sparar datum- och tidsstämplar enligt den lokala tidszonen, när den ändras ändras inte märkena.

Tidsstämplar för kataloger ställs in när de skapas och ändras inte när nya filer skrivs till en katalog, byter namn eller ett nytt kluster tilldelas den.

Filens senaste åtkomstdatum uppdateras varje gång den öppnas, till exempel när du visar filens egenskaper, när du flyttar till en annan volym (men inte inom volymen). När du kopierar en fil i Windows 98 uppdateras det senaste åtkomstdatumet för originalfilen, men inte i Windows XP.

Filändringens datum och tid ändras när nytt innehåll skrivs till dataområdet (inte filposten). Med andra ord ändras inte ändringens datum-tid när attribut ändras eller filen byter namn. Om du flyttar eller kopierar en fil behålls det ursprungliga ändringsmärket.

Skapandets datum och tid ställs in när en filpost tilldelas för en ny fil som inte fanns tidigare. Med andra ord, när en fil döps om eller flyttas ändras inte datum och tid för skapande, men när den kopieras får den nya filen en ny stämpel. När du kopierar en fil på Windows kan den alltså sluta med ett skapandedatum som är senare än ändringsdatumet.

LFN-poster

Filer och kataloger med ett långt namn (större än 8.3) behandlas på ett speciellt sätt av FAT-filsystemet. Strukturen för en 32-byte-post för en fil med ett LFN (Long File Name) skiljer sig från en vanlig (SFN)-post:

  • LDIR_Ord. Den första byten i en post används för att numrera posterna i uppsättningen.
  • LDIR_Name1. 10-byte-fältet på adress 0x01 innehåller de första fem tecknen i filnamnet (eller snarare den del av dess namn som återspeglas i denna LFN-post).
  • LDIR_Attr. Attributbyten vid adress 0x0B är 0x0F (ATTR_LONG_NAME).
  • LDIR_Typ. Byten på adressen 0x0C är noll och indikerar dessutom att denna post i FAT-tabellen refererar till en fil med ett långt namn.
  • LDIR_Chksum. Byten vid adress 0x0D innehåller SFN-kontrollsumman för filaliaset som motsvarar uppsättningen LFN-poster.
  • LDIR_Name2. Ett 12-byte fält på adress 0x0E som innehåller tecknen 6 till 11 i filnamnet.
  • LDIR_FstClusLO. 2-byte-fältet vid adress 0x1A är meningslöst i sammanhanget för en LFN-post och sätts till noll.
  • LDIR_Name3. Ett 4-byte fält på adress 0x1C som innehåller de 12:e och 13:e tecknen i filnamnet.

En uppsättning LFN-poster i en FAT-katalog måste alltid associeras med en vanlig SFN-post som fysiskt föregås på disken. En uppsättning LFN-poster som hittas utan en motsvarande normal post kallas för föräldralös , och posten anses vara korrupt; en sådan fil är helt osynlig i äldre versioner av MS-DOS/Windows.

I en sekvens av LFN-poster har var och en av dem sitt eget serienummer, bestämt av den första byten (LDIR_Ord). 0x40-masken indikerar att denna post är den sista i raden av LFN-poster efter den (det vill säga, till exempel, för den tredje LFN-posten i raden, kommer värdet på LDIR_Ord-byten att vara 0x43, för den 17:e - 0x51 ). I efterföljande poster ändras denna byte från N för den N:te "långa" posten i kontot från motsvarande normala till 1 för den som ligger närmast den normala posten.

Långa filnamn lagras i Unicode ( UTF-16 )-kodning, vilket behåller skiftläge för de inmatade alfabetiska tecknen. Om ett visst OEM- eller Unicode-namntecken inte kan konverteras till ett teckentabellstecken, visas det alltid som understreckstecknet "_" och det faktiska tecknet som lagras på disken ändras inte.

Kontrollsummans byte beräknas enligt en viss algoritm baserad på 8.3-namnet på en vanlig post (för en fil med ett långt namn kallas "namnet" från en vanlig post ett alias - alias) och kopieras till alla "long " register som motsvarar den. Om något av värdena inte stämmer överens med filnamnet (till exempel om filen döptes om under en tidig version av MS-DOS/Windows), uppstår ett föräldralöst namn.

Ett SFN-filalias med ett långt namn består av en kropp och vid behov en digital "svans". Om filen har en filändelse lagras dess tre första tecken i aliaset. Motsvarande namn bildas genom att översätta tecknen i det långa filnamnet till OEM-kodningen, där alla mellanslag i det långa namnet ignoreras, och tecken som inte är översättbara i OEM eller förbjudna i sammanhanget med det korta namnet ersätts med ett understreck "_". Siffran svans "~n", där n = 1 ÷ 999999, läggs till aliaset om det ursprungligen erhållna aliaset kom i konflikt med namnet på någon fil i samma katalog eller var längre än 8.3-standarden definierar, eller om något tecken när att ändra kodning hittade ingen OEM-motsvarighet och ersattes av ett understreck. Sålunda bildas alias som NEWFIL~1.DJV (LFN = New file for me.djvu). Filaliasingschemat är optimerat för hastighet och är därför oförutsägbart i detalj.

Ett filnamn som inte är en multipel av 13 tecken fyller inte helt i namnfälten för LFN-poster i FAT-tabellen. I det här fallet avslutas filnamnet artificiellt med ett NUL-tecken (0x00), och överflödiga byte är tilltäppta med ettor (det vill säga med 0xFF-tecken).

För långa namn är längden på namnet begränsad till 255 tecken, NUL-avgränsaren inte räknad, och den fullständiga sökvägen är begränsad till 260 tecken, inklusive NUL. Det långa namnet tillåter också användning av sex specialtecken som är förbjudna i korta namn: +,; =[]

Om du försöker skapa en fil eller katalog på en FAT32-volym med ett namn som innehåller ett sådant tecken, genereras en LFN-post automatiskt, oavsett filnamnets längd. En liknande process inträffar när du skapar en fil/mapp med ett namn som innehåller icke-ASCII-tecken.

Det är möjligt att volymetikettsfilen inte fysiskt föregår alla poster i volymen med långa namn (när volymen inte har en etikett, eller etiketten tilldelades efter att någon fil med ett långt namn skrevs). Då kommer inte volymetiketten i FAT12/FAT16 att visas korrekt, eftersom den tas från närmaste LFN-post (eftersom den även har attributet VOLUME_ID), och om du försöker ändra volymetiketten, namnet på motsvarande fil faktiskt kommer att kränkas. När du raderar en fil som har associerade LFN-poster påverkas inte de senare och blir föräldralösa. Under det fortsatta skapandet av en ny fil kan den nämnda föräldralösa filen felaktigt associeras med den om kontrollsummorna för namnen på de gamla och nya filerna stämmer överens med den kontrollsummaberäkningsalgoritm som används (ASCII-koden för det första tecknet i filen alias skiftas cykliskt med en bit åt höger och koden för nästa tecken läggs till, etc. d) gör denna sannolikhet försumbar.

Betydelse av filoperationer i FAT

Volymformatering  - indexpekartabellen återställs till noll, förutom de tre första (FAT[0] och FAT[1], är reserverade och FAT[2] innehåller en post som motsvarar volymetikettfilen, eller, om den saknas, EOC-etiketten) och register över skadade kluster; rotkatalogposterna sätts till noll (förutom volymetikettfilen, om någon), annars påverkas inte dataområdet.

Filradering  - det första tecknet i filposten och alla associerade LFN-poster ersätts med koden 0xE5; klustren som upptas av filen är markerade som lediga i FAT-tabellen, men klustren i dataområdet påverkas inte.

Skapa en fil eller katalog med kommandot "Ny" i snabbmenyn - en filpost skapas för en ny "tom" fil med ett standardnamn (till exempel "Ny mapp") och en storlek som bestäms av filtypen; själva filen, om den har en storlek som inte är noll (vilket är sant för nästan alla "tomma" filer, förutom kataloger och textdokument), skrivs till dataområdet i de kluster som tilldelats den; motsvarande klusterkedja skapas i FAT-tabellen. Efter att ha gett filen ett giltigt namn (inte standard), markeras den ursprungligen skapade filposten som raderad och en ny skapas.

Byta namn på en fil  - en ny post skapas med ett uppdaterat namn; den gamla posten markeras som raderad.

Spara en fil från programmet (inte från kommandoraden) - en post skapas som innehåller alla fält utom storleken och det initiala klustret för filen; efter att filen har sparats skapas en ny post som innehåller alla fält och den gamla posten raderas.

Kopiera en fil  - en identisk filpost skapas på den nya platsen (möjligen med undantag för vissa tidsstämplar, se ovan), det första lediga klustret tilldelas filen och innehållet i filen kopieras till den nya platsen, samtidigt som nuvarande kluster, söker efter nästa lediga och fyller FAT-tabellen .

Flytta en fil (mellan olika volymer) - kopiera och sedan ta bort filen från dess ursprungliga plats.

Filflyttning (inom volymen) - klusterkedjan påverkas inte, filposten kopieras oförändrad till den nya katalogen och raderas sedan från den gamla.

Sökningen efter ett ledigt kluster i tabellen med indexpekare för allokering till en ny fil börjar vanligtvis inte från början av dataområdet (det vill säga från kluster 2), utan från det sista klustret som allokerats till någon fil, antalet som lagras i FSInfo-strukturen. Med andra ord, om fil 1 tilldelades kluster 30, och fil 2 tilldelades kluster 31, och sedan fil 1 togs bort, då när en ny fil 3 skapas, kommer den med största sannolikhet att vara fysiskt lokaliserad från kluster 32.

Systemfelstolerans

Eftersom FAT-systemet lagrar data om filer och data om ledigt diskutrymme i samma tabell, består filskrivoperationen, som traditionellt sett består av två steg (att lägga till det upptagna blocket till listan över upptagna och ta bort samma block från listan med fria), förekommer i FAT i en åtgärd. På grund av detta har FAT-systemet en inneboende feltolerans, det vill säga ett fel (till exempel ström) vid tidpunkten för en läs- eller skrivoperation kommer i de flesta fall inte att leda till att filsystemet förstörs. Men i det här fallet talar vi om filsystemets integritet och inte själva filerna.

Egenskaper [3]

FAT12 FAT16 FAT32
Utvecklaren Microsoft
Hela titeln Filfördelningstabell
(12 bitars version) (16-bitars version) (32-bitarsversion)
Presenteras 1980 ( Microsoft Disk BASIC ) Augusti 1984 ( MS-DOS 3.00, trunkerad)
full – juli 1988, MS-DOS 4.0 [6]		 Augusti 1996 (Windows 95 OSR 2)
Volym-ID 0x01 ( MBR ) 0x04, 0x06, 0x0E (MBR) 0x0B, 0x0C (MBR)
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT )
strukturer
Kataloginnehåll Tabell
Filplacering Linjär lista
Dåliga block Klustertaggning
Restriktioner
filstorlek 32MB _ 2 GB _ 4 GB
Antal kluster 4084 65 524 268 435 445 (2 28 −12)
Filnamnets längd 8,3 eller 255 tecken när du använder LFN
Volymstorlek 2 MB (512 byte per sektor)

32 MB (64 KB per kluster)

2 GB
4 GB (64 KB per kluster, stöds inte överallt)		 2 TB
8 TB (32 KB per sektor)
Förmågor
Lagrade datum Skapande, modifiering, åtkomst
Datumintervall 1 januari 1980 - 31 december 2107
Ytterligare information Till en början inte stöds
Filattribut Skrivskyddad, dold, system, volymetikett, underkatalog, arkiv
Differentiering av åtkomsträttigheter Inte
Transparent kompression Fristående verktyg ( Stacker , DoubleSpace , DriveSpace )
Transparent kryptering Tredjepartsverktyg eller DOS-kloner

Licensiering

Vissa algoritmer för att arbeta med FAT och VFAT är patenterade av Microsoft.

I USA på omprövning[ när? ] beslutades att upphäva några av patenten, men sedan upphävdes det.

I oktober 2006 annullerades ett patent för VFAT utfärdat av Europeiska patentverket [7] i Tyskland för självklarheten .

Med tiden blev FAT flitigt använt i olika enheter för kompatibilitet mellan DOS, Windows, OS/2, Linux. Microsoft har inte visat någon avsikt att tvinga dem att licensiera[ förtydliga ] [8] .

I februari 2009 stämde Microsoft TomTom , en tillverkare av Linux -baserade bilnavigeringssystem , för patentintrång [9] .

Enligt Jeremy Ellison[ förtydliga ] Microsofts mål är att ge olika företag ett val: ingå ett patentskyddsavtal med Microsoft (som Novell ingick med Microsoft i november 2006), och därmed bryta mot GNU GPL och göra det omöjligt för dem själva att använda Linux , eller inte ingå ett sådant avtal och bli anklagad för att göra intrång i patent, vars skydd ges när det ingås under villkoret av sekretess [10] [11] .

I mars 2009 lämnade TomTom in ett genkäromål för patentintrång [12] .

Se även

Anteckningar

  1. ↑ Arkiverad kopia . Hämtad 9 juni 2009. Arkiverad från originalet 16 juli 2011.
  2. ↑ www.microsoft.com/mscorp/ip/tech/fathist.asp på archive.org
  3. ↑ 1 2 Microsoft Extensible Firmware Initiative FAT32 filsystemspecifikation 1.03 (länk ej tillgänglig) . Microsoft (6 december 2000). — Dokument i Microsoft Word-format, 268 Kb. Hämtad 5 april 2010. Arkiverad från originalet 22 augusti 2011. 
  4. ↑ Vad sägs om VFAT? (inte tillgänglig länk) . TechNet Arkiv . Microsoft (15 oktober 1999). Hämtad 5 april 2010. Arkiverad från originalet 22 augusti 2011. 
  5. ↑ Blanda inte ihop filsystemtillägget VFAT med filsystemdrivrutinen med samma namn, som dök upp i Windows for Workgroups 3.11 och är utformad för att behandla MS-DOS-funktionsanrop (INT 21h) i skyddat läge (se: KB126746: Windows för Workgroups Versionshistorik (inte tillgänglig (länk) VERSION 3.11 → Icke-nätverksfunktioner Microsoft (14 november 2003) Hämtad 5 april 2010. Arkiverad från originalet 22 augusti 2011.  )
  6. ↑ MS-DOS-partitioneringssammanfattning (nedlänk) . microsoft.com . Hämtad 23 oktober 2012. Arkiverad från originalet 23 oktober 2012. 
  7. ↑ Federal Patent Court förklarar Microsofts FAT-patent ogiltigt  (engelska)  (länk ej tillgänglig) . heise online . Heise Zeitschriften Verlag (2 mars 2007). Hämtad 10 mars 2009. Arkiverad från originalet 22 augusti 2011.
  8. ↑ Brian Kahin. Microsoft Roils the World med FAT-patent  (engelska)  (länk ej tillgänglig) . The Huffington Post (10 mars 2009). Hämtad 10 mars 2009. Arkiverad från originalet 22 augusti 2011.
  9. ↑ Ryan Paul. Microsofts process över FAT-patent kan öppna OSS Pandora's Box  (eng.)  (inte tillgänglig länk) . Ars Technica . Condé Nast Publications (25 februari 2009). Hämtad 9 mars 2009. Arkiverad från originalet 22 augusti 2011.
  10. ↑ Glyn Moody. Den verkliga anledningen till Microsofts TomTom-process  (engelska)  (länk ej tillgänglig) . datorvärlden Storbritannien . IDG (5 mars 2009). Hämtad 9 mars 2009. Arkiverad från originalet 22 augusti 2011.
  11. ↑ Steven J. Vaughan-Nichols. Linux-företag undertecknar Microsofts patentskyddsavtal  (eng.)  (inte tillgänglig länk) . Computerworld Bloggar . IDG (5 mars 2009). Hämtad 9 mars 2009. Arkiverad från originalet 22 augusti 2011.
  12. ↑ Erica Ogg. TomTom bestrider Microsoft i patenttvist  (eng.)  (inte tillgänglig länk) . CNet (19 mars 2009). Hämtad 20 mars 2009. Arkiverad från originalet 22 augusti 2011.

Länkar

 Ecma internationella standarder