FAT ( engelsk File Allocation Table "filallokeringstabel") er en klassisk filsystemarkitektur , som på grund af sin enkelhed stadig er meget brugt til flashdrev . Bruges i disketter , hukommelseskort og nogle andre lagermedier. Tidligere blev det også brugt på harddiske.
Udviklet af Bill Gates og Mark McDonald i 1976-1977 [1] [2] . Det blev brugt som hovedfilsystemet i operativsystemerne i MS-DOS- og Windows 9x -familierne .
FAT-strukturen følger ECMA-107-standarden og er defineret i detaljer af den officielle Microsoft-specifikation kendt som FATGEN [3] .
Der er fire versioner af FAT - FAT12 , FAT16 , FAT32 og exFAT (FAT64) . De adskiller sig i bitheden af poster i diskstrukturen, det vil sige antallet af bits , der er reserveret til lagring af klyngenummeret. FAT12 bruges hovedsageligt til disketter , FAT16 til små diske. Baseret på FAT blev der udviklet et nyt exFAT (extended FAT) filsystem, der primært bruges til flashdrev .
Oprindeligt understøttede FAT ikke et hierarkisk katalogsystem - alle filer var placeret i roden af disken. Dette blev gjort for nemheds skyld, da det på enkeltsidede disketter med en kapacitet på kun 160–180 KB, simpelthen ikke gav mening at sortere nogle få filer i mapper. Med spredningen af disketter på 320 eller flere kilobyte viste det sig at være ubelejligt at gemme alle filer i roden, desuden begrænsede den lille størrelse af rodmappen antallet af filer på disken. Mapper blev introduceret med udgivelsen af MS-DOS 2.0.
Forskellige operativsystemer har også implementeret forskellige FAT-udvidelser. For eksempel har DR-DOS yderligere filadgangsattributter; i Windows 95 , Linux - understøttelse af lange filnavne (LFN) i Unicode-format (Virtual FAT - VFAT); på OS/2 udvidede attributter for alle filer.
VFAT er en FAT-udvidelse introduceret i Windows 95 . I FAT er filnavne i 8.3 -format og består kun af ASCII-tegn . Understøttelse af lange (op til 255 tegn) filnavne ( Long File Name, LFN ) i UTF-16LE- kodning blev tilføjet til VFAT , mens LFN'er gemmes samtidigt med navne i 8.3-format, retrospektivt kaldet SFN ( Engelsk Short File Name ). LFN'er er ufølsomme for store og små bogstaver, når de slår op, men i modsætning til SFN'er, som er gemt med store bogstaver, beholder LFN'er det angivne store og små bogstaver, da filen blev oprettet [4] [5] .
I FAT-filsystemet kombineres sammenhængende disksektorer til enheder kaldet klynger . Antallet af sektorer i en klynge er lig med en potens af to (se nedenfor). Et helt antal klynger (mindst én) er allokeret til lagring af fildata, så hvis f.eks. filstørrelsen er 40 bytes, og klyngestørrelsen er 4 KB, vil kun 1 % af den plads, der er allokeret til den, faktisk være optaget af filoplysningerne. For at undgå sådanne situationer er det tilrådeligt at reducere størrelsen af klynger og omvendt for at reducere mængden af adresseoplysninger og øge hastigheden af filoperationer. I praksis er der valgt et kompromis. Da diskkapaciteten meget vel ikke kan udtrykkes i et heltal af klynger, er der normalt i slutningen af volumen såkaldte overskudssektorer - en "rest" mindre end en klynge i størrelse, som ikke kan allokeres af OS til lagring af information.
FAT32-volumenrummet er logisk opdelt i tre sammenhængende områder:
FAT12 og FAT16 har også et dedikeret område til rodmappen. Den har en fast position (umiddelbart efter det sidste element i FAT-tabellen) og en fast størrelse i 32-byte-elementer, det vil sige, når man beskriver i Partition Boot Record, er det netop antallet af 32-byte-elementer, der er angivet , som hver beskriver ethvert element i rodmappen (det være sig fil eller anden undermappe).
Hvis en klynge hører til en fil, så indeholder den tilsvarende celle i FAT-tabellen nummeret på den næste klynge i den samme fil. Hvis cellen svarer til den sidste klynge i filen, så indeholder den en speciel værdi (0xFFFF for FAT16). Der er således bygget en kæde af filklynger. Nuller svarer til ubrugte klynger i tabellen. "Dårlige" klynger (som er udelukket fra behandling, for eksempel fordi det tilsvarende område af enheden er ulæseligt) har også en speciel kode (0xFFF7 for FAT16).
Når en fil slettes, erstattes det første tegn i navnet med specialkoden 0xE5, og filens klyngekæde i allokeringstabellen nulstilles. Da oplysningerne om filstørrelsen (som er placeret i mappen ved siden af filnavnet) forbliver intakte, kan den slettede fil gendannes, hvis filklyngerne var placeret sekventielt på disken og ikke blev overskrevet med nye oplysninger.
Den første struktur af en FAT-volumen kaldes BPB ( BIOS -parameterblok ) og er placeret i et reserveret område i sektor nul. Denne struktur indeholder information, der identificerer typen af filsystem og mediets fysiske karakteristika (diskette eller harddiskpartition).
BIOS Parameter Block (BPB)BPB udeblev fra FAT, som tjente MS-DOS 1.x, da man på det tidspunkt kun antog to forskellige typer volumener - enkeltsidede og dobbeltsidede 5-tommers 320 KB disketter, og volumenformatet blev bestemt af den første byte i FAT-området. BPB blev introduceret i MS-DOS 2.x i begyndelsen af 1983 som en obligatorisk opstartssektorstruktur, hvorfra volumenformatet kan bestemmes fremover; det gamle FAT first byte detektionsskema blev ikke længere understøttet. Også i MS-DOS 2.0 blev et hierarki af filer og mapper introduceret (før det var alle filer gemt i rodmappen).
BPB-strukturen i MS-DOS 2.x indeholdt et 16-bit "samlet antal sektorer"-felt, hvilket betød, at denne version af FAT var fundamentalt uanvendelig for volumener større end 2 16 = 65.536 sektorer, det vil sige mere end 32 MB med en standardsektorstørrelse på 512 bytes. I MS-DOS 4.0 (1988) blev BPB-feltet udvidet til 32 bit, hvilket betød en stigning i den teoretiske volumenstørrelse til 232 = 4.294.967.296 sektorer, dvs. op til 2 TB med en 512-byte sektor.
Den næste ændring af BPB dukkede op med Windows 95 OSR2, som introducerede FAT32 (i august 1996). Grænsen på 2 TB for volumenstørrelse er blevet fjernet, en FAT32-volumen kan teoretisk være op til 8 TB i størrelse. Størrelsen af hver enkelt fil må dog ikke overstige 4 GB. BIOS-parameterblokken i FAT32, for kompatibilitet med tidligere versioner af FAT, gentager BPB fra FAT16 til og med BPB_TotSec32-feltet efterfulgt af forskelle.
FAT32 "boot-sektoren" er faktisk tre 512-byte sektorer - sektorer 0, 1 og 2. Hver af dem indeholder signaturen 0xAA55 på adressen 0x1FE, det vil sige i de sidste to bytes, hvis sektorstørrelsen er 512 bytes. Hvis sektorstørrelsen er mere end 512 bytes, er signaturen indeholdt både på adressen 0x1FE og i de sidste to bytes af nulsektoren, det vil sige, at den duplikeres.
FSInfoOpstartsrecorden for en FAT32-partition indeholder en struktur kaldet FSInfo , der bruges til at lagre værdien af volumenets frie klyngeantal. FSInfo optager som regel sektor 1 (se feltet BPB_FSInfo) og har følgende struktur (adresser i forhold til begyndelsen af sektoren):
Pointen med at introducere FSInfo er at optimere driften af systemet, da indekspointertabellen i FAT32 kan være meget stor, og dens byte-for-byte-opslag kan tage lang tid. Værdierne af felterne FSI_Free_Count og FSI_Nxt_Free svarer dog muligvis ikke til virkeligheden og bør kontrolleres for tilstrækkelighed. Derudover er de ikke engang opdateret i FSInfo backup, som normalt er placeret i sektor 7.
Bestemmelse af typen af FAT-volumenBestemmelse af FAT-typen af et volumen (det vil sige valget mellem FAT12, FAT16 og FAT32) foretages af OS baseret på antallet af klynger i volumenet, som igen bestemmes ud fra BPB-felterne. Først og fremmest beregnes antallet af sektorer i rodmappen:
RootDirSectors = (BPB_RootEntCnt * 32) / BPB_BytsPerSecDernæst bestemmes det, hvilke af felterne BPB_FATSz16/32 og BPB_TotSec16/32 der ikke er lig med nul, og de bruges til at bestemme antallet af sektorer i volumendataområdet:
DataSec = TotSec - (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) + RootDirSectors)Til sidst bestemmes antallet af dataområdeklynger:
CountofClusters = DataSec / BPB_SecPerClus
Ved antallet af klynger er der en en-til-en korrespondance med filsystemet:
Ifølge den officielle specifikation er dette den eneste gyldige måde at bestemme FAT-typen på. Kunstig oprettelse af en volumen, der overtræder de angivne kortlægningsregler, vil medføre, at den bliver håndteret forkert af Windows. Det anbefales dog at undgå værdier af CountofClusters, der er tæt på de kritiske værdier (4085 og 65525) for korrekt at bestemme filsystemtypen af eventuelle, ofte forkert skrevne, drivere.
FAT12 oprettes altid på en diskette, når det formateres . Hvad angår harddiske og flashdrev , så med en drevstørrelse på op til 512 MB (med en 512-byte sektor), oprettes FAT16 som standard, over 512 MB - FAT32. Klyngestørrelsen bestemmes under formatering baseret på filsystemet og volumenstørrelsen.
Bindets serienummerVolumens serienummer (feltet BS_VolID) i Windows 98 oprettes ud fra formatet dato og klokkeslæt på en sådan måde, at det er umuligt at gendanne dem uden yderligere oplysninger.
Den næste vigtige struktur i et FAT-volumen er selve FAT-tabellen, som optager et separat logisk område. Den definerer en liste (kæde) af klynger, der er vært for diskenhedens filer og mapper. Der er en en-til-en overensstemmelse mellem klynger og indeksmarkører i tabellen - den N'te pointer svarer til klyngen med samme nummer. Den første klynge i dataområdet er tildelt nummeret 2. Indeksmarkørens værdi svarer til tilstanden for den tilsvarende klynge. Følgende tilstande er mulige:
Klynger 0 og 1 afspejles separat af FAT. Indeksmarkøren svarende til klynge nul (den allerførste FAT tabel pointer) indeholder værdien af BPB_Media i de nederste 8 bits; de resterende bit er sat til 1. For eksempel, hvis BPB_Media = 0xF8 (harddisk), FAT[0] = 0x0FFFFFF8 for FAT32. Således formelt FAT[0] = EOC, som bruges ved behandling af filer i nulstørrelse (se nedenfor).
Den anden reserverede markør, FAT[1], er indstillet til værdien af EOC-mærket ved formatering. I FAT12 bruges den ikke længere på nogen måde, og i FAT16 og FAT32 kan de øverste to bits af denne pointer indeholde et mærke om behovet for at kontrollere lydstyrken (den såkaldte " dirty bit ") og alle andre bits er sat til 1. Tilstedeværelsen af en snavset bit kontrolleres under Windows boot-processen autochk.exe-programmet. Den beskidte bit genereres, når lydstyrken ikke er korrekt afmonteret, eller når mediet har en hardwarefejl og derfor tager to mulige værdier.
En FAT32-indeksmarkør er per definition 32 bit, men de øverste 4 bits ignoreres faktisk, så værdien af pointeren er faktisk 28 bit. Den eneste handling, der fungerer på de øverste 4 bits af markøren, er volumenformatering, som nulstiller hele markøren. Det betyder, at f.eks. pointerværdierne 0x10000000, 0xF0000000 og 0x00000000 alle svarer til en fri klynge, da de kun adskiller sig i de øverste 4 bits.
Værdien af BPB FAT-tabelstørrelsen, dvs. BPB_FATSz16/32, kan være større end den reelle, så der kan være sektorer i slutningen af hver FAT-tabel, som ikke svarer til nogen reelle dataklynger. Under formatering nulstilles disse sektorer, og under driften af volumen bruges de ikke på nogen måde. Derfor skal den faktiske adresse for den sidste sektor i FAT-tabellen, som indeholder pointere til reelle volumen-klynger, altid beregnes ud fra det samlede antal dataområde-klynger og ikke fra BPB_FATSz16/32-feltet. Derudover er den sidste sektor optaget af FAT-tabellen ikke nødvendigvis helt optaget af den - i dette tilfælde bruges sektorens overskydende plads heller ikke og er fyldt med nuller ved formatering af volumen.
Umiddelbart efter slutningen af den sidste FAT-tabel er et dataområde, der indeholder filer og mapper. Et FAT- bibliotek er en almindelig fil markeret med en speciel egenskab. Dataene (indholdet) af en sådan fil i enhver FAT-version er en kæde af 32-byte filposter (mappeposter). En mappe kan normalt ikke indeholde to filer med samme navn. Hvis kontroldiskprogrammet finder et kunstigt oprettet par identisk navngivne filer i samme mappe, omdøbes en af dem.
RodmappeDen eneste mappe, der skal være til stede, er rodmappen. I FAT12/FAT16 har rodmappen en fast størrelse i sektorer, som beregnes ud fra værdien af BPB_RootEntCnt, og følger FAT-tabellen på disken.
I FAT32 har rodmappen, som enhver anden, en variabel størrelse og er en kæde af klynger. Nummeret på den første rodbiblioteksklynge afspejles af BPB_RootClus. Rodbiblioteket adskiller sig fra andre mapper på en FAT-diskenhed på følgende måder:
En FAT32-filpost består af følgende strukturer:
Hvis den første byte af en FAT-indgang (det vil sige DIR_Name[0]) indeholder 0xE5 eller 0x05, betyder det, at posten er fri (den tilsvarende fil er blevet slettet). Nul i DIR_Name[0] betyder, at ikke kun denne post er gratis, men også alle efterfølgende katalogposter; Windows analyserer ikke resten af en mappe efter en nulstillet post.
Filnavn i FATDIR_Name-feltet er logisk opdelt i de første 8 tegn, som danner filnavnet, og de sidste 3, som danner udvidelsen. Separatorperioden tilføjes på operativsystemniveau og gemmes ikke i navnefeltet. Hvis filnavnet og filtypenavnet ikke udfylder den plads, der er tildelt dem, bliver de resterende bytes i feltet DIR_Name fyldt med mellemrum (0x20). Filnavnet og filtypenavnet kan indeholde enhver kombination af bogstaver, tal eller tegn med ASCII - koder større end 127; specialtegn er opdelt i tre grupper:
Tjenestetegn har en særlig betydning i DOS og Windows og kan ikke være en del af et filnavn (tegn * ? er metategn , og tegn : / \ bruges som separatorer i filstier , andre servicetegn og ulovlige tegn er kontroltegn i kommandolinjefortolkere COMMAND. COM og cmd.exe ), mens forbudte tegn stadig kan inkluderes i filnavnet på bekostning af en LFN-indgang (se nedenfor). For eksempel kan en mappe med et navn, der starter med en prik eller indeholder flere prikker, oprettes i kommandolinjetilstand ( mkdir .directory) eller i skaller som FAR Manager , Total Commander , WinRAR . Filnavnet kan ikke starte eller slutte med et mellemrum; ingen ASCII-kontroltegn (det vil sige 0x00-0x1F) er tilladt i nogen byte i navnefeltet, bortset fra tilfældet med kode 5, der er angivet ovenfor. Oplysninger om den aktuelle (på det tidspunkt, hvor filen blev oprettet) DOS -kodetabel er ikke gemt, så adgang til filer, hvis navne indeholder nationale koder fra Extended ASCII (f.eks. kyrilliske tegn fra kodetabel 866 ), med en anden tegntabel, kan det være problematisk eller umuligt (fordi før du søger efter en fil i mappen, navn konverteres til store bogstaver i overensstemmelse med tabellen i kodebladet). Den fulde sti til filen må ikke overstige 80 bytes (3 er drevbogstavet; 64 er stien; 12 er filnavnet, inklusive afgrænsningspunktet; 1 er terminalens nultegnet).
Alle 8,3 alfabetiske tegn i navnet oversættes altid og gemmes i feltet DIR_Name med store bogstaver. DIR_NTRes-byten bruges til at bevare det oprindelige store og små bogstaver i et Windows NT - navn: 1 i bit 3 fortæller, at navnet skal vises med små bogstaver; Det er bit 4, der er ansvarlig for udvidelsen Hvis navnet eller udvidelsen indeholder tegn fra begge tilfælde, oprettes en LFN-record for en sådan fil (se nedenfor). Windows 9x opretter altid en LFN-post for at bevare navnets ikke-trivielle store og små bogstaver og ignorerer feltet DIR_NTRes. Som en konsekvens heraf kan navnet på den samme fil, uden en tilknyttet LFN-post, blive vist af Windows 9x udelukkende med store bogstaver, men Windows NT (delvis) med små bogstaver.
FilattributterI attributbyten er de to øverste bits reserverede og skal altid sættes til nul. De resterende bits er fordelt på en sådan måde, at værdien 0x01 svarer til "read-only" attributten, 0x02 - "skjult", 0x04 - "system", 0x20 - "arkiveret". Et sæt af flere attributter er lavet ved at summere de grundlæggende værdier. Ud over disse standardattributter bruges følgende: 0x10 - angiver, at filen er en mappe (beholder til andre filer); 0x08 - ATTR_VOLUME_ID, en speciel attribut for en unik nul-størrelse fil i rodmappen, hvis navn anses for at være en volumen etiket. Grænsen på 11-tegns FAT-volumenetiketten er relateret til størrelsen af feltet DIR_Name. Hvis filen har READ_ONLY | SKJULT | SYSTEM | VOLUME_ID (værdi 0x0F), dette indikerer, at indgangen ikke svarer til en separat fil, men indeholder en del af et langt navn på en anden fil, der ikke passer ind i 8.3-rammeværket (se nedenfor).
En kunstig tildeling af en værdi, der ikke er nul, til de øverste to bits af DIR_Attr bruges til at danne filer, der ikke kan slettes eller omdøbes med standardmidler i filsystemet uden formatering. Dette er f.eks. nyttigt, når du bekæmper Autorun.inf-virus (Panda USB og AutoRun Vaccine-programmet). På den anden side kan virus selv bruge det samme værktøj. Værdien af DIR_Attr = 0x40 er reserveret til intern brug (enhed).
Hvad sker der, når en mappe oprettesNår en mappe er oprettet, er DIR_FileSize = 0 sat til den "for life".Størrelsen af mappens indhold bestemmes ved blot at følge kæderne af klynger op til End Of Chain-mærket. Størrelsen af selve mappen er begrænset af filsystemet til 65.535 32-byte poster (det vil sige, mappeposter i FAT-tabellen må ikke overstige 2 MB). Denne grænse er beregnet til at fremskynde filoperationer og tillade forskellige hjælpeprogrammer at bruge et 16-bit heltal (WORD) til at tælle antallet af poster i en mappe (som følge heraf er der en teoretisk grænse for antallet af filer i en mappe - 65.535, forudsat at alle filnavne følger standarden 8.3). Biblioteket er tildelt én dataområde-klynge (medmindre det er en FAT12/FAT16-rodmappe), og DIR_FstClusHI / DIR_FstClusLO-felterne indstilles til værdien af det klyngenummer. En EOC-label er placeret i FAT-tabellen for den post, der svarer til denne klynge, og selve klyngen er fyldt med nuller. Derefter oprettes to specielle filer, uden hvilke FAT-biblioteket anses for at være beskadiget (de første to 32-byte-indgange i klyngedataområdet) - nulstørrelsesfiler med navnene "." (én prik, mappe-id) og ".." (to prikker, pegepind til den overordnede mappe). Dato- og tidsstemplerne for disse filer er indstillet til værdierne for selve mappen på oprettelsestidspunktet og opdateres ikke, når mappen ændres. DIR_FstClusHI / DIR_FstClusLO felterne i "." indeholde værdien af nummeret på den klynge, der indeholder det, og filen ".." - nummeret på den første klynge i den mappe, der indeholder den givne. Således filen "." refererer til selve mappen, og filen ".." refererer til den oprindelige klynge af den overordnede mappe; hvis det overordnede bibliotek er rodbiblioteket, anses den oprindelige klynge for at være nul.
Tid og datoEt to-byte datostempel har følgende format:
Et to-byte tidsstempel har følgende format:
Af dato- og tidsstemplerne er kun det sidste ændringstidspunkt (det vil sige DIR_WrtTime og DIR_WrtDate) kritisk, resten understøttes muligvis ikke af mange systemer; når du opererer på en fil på et sådant system (for eksempel i DOS eller Windows 3.1), ignoreres disse felter. FAT gemmer dato- og tidsstempler i henhold til den lokale tidszone; når den ændres, ændres mærkerne ikke.
Tidsstempler for mapper indstilles, når de oprettes og ændres ikke, når nye filer skrives til en mappe, omdøbes, eller en ny klynge tildeles den.
Filens sidste adgangsdato opdateres, hver gang den tilgås, f.eks. når du ser filens egenskaber, når du flytter til en anden diskenhed (men ikke inden for diskenheden). Når du kopierer en fil i Windows 98, opdateres den sidste adgangsdato for den originale fil, men ikke i Windows XP.
Dato-klokkeslæt for filændring ændres, når nyt indhold skrives til dataområdet (ikke filposten). Med andre ord ændres ændringsdato-tid ikke, når attributter ændres, eller filen omdøbes. Flytning eller kopiering af en fil bevarer det originale ændringsmærke.
Oprettelsesdatoen og -tidspunktet indstilles, når en filpost tildeles til en ny fil, der ikke eksisterede før. Med andre ord, når en fil omdøbes eller flyttes, ændres datoen og tidspunktet for oprettelsen ikke, men når den kopieres, får den nye fil et nyt stempel. Når en fil kopieres på Windows, kan den således ende med en oprettelsesdato, der er senere end ændringsdatoen.
Filer og mapper med et langt navn (større end 8.3) behandles på en særlig måde af FAT-filsystemet. Strukturen af en 32-byte record for en fil med et LFN (Long File Name) er forskellig fra en almindelig (SFN) record:
Et sæt LFN-poster i en FAT-mappe skal altid være knyttet til en almindelig SFN-post, der er fysisk foran på disken. Et sæt LFN-poster fundet uden en tilsvarende normal post kaldes en forældreløs , og posten betragtes som korrupt; sådan en fil er fuldstændig usynlig i ældre versioner af MS-DOS/Windows.
I en sekvens af LFN-poster har hver af dem sit eget serienummer, bestemt af den første byte (LDIR_Ord). 0x40-masken angiver, at denne post er den sidste i rækken af LFN-poster efter den (det vil sige, for eksempel, for den tredje LFN-post i rækken, vil værdien af LDIR_Ord-byten være 0x43, for den 17. - 0x51 ). I efterfølgende poster ændres denne byte fra N for den N-te "lange" post i kontoen fra den tilsvarende normal til 1 for den, der er tættest på den normale post.
Lange filnavne gemmes i Unicode ( UTF-16 )-kodning, hvilket bevarer store og små bogstaver i de indtastede alfabetiske tegn. Hvis et bestemt OEM- eller Unicode-navntegn ikke kan konverteres til et tegntabel, vises det altid som understregningstegnet "_", og det faktiske tegn, der er gemt på disken, ændres ikke.
Kontrolsumbyten beregnes i henhold til en bestemt algoritme baseret på 8.3-navnet på en almindelig post (for en fil med et langt navn kaldes "navnet" fra en almindelig post et alias - alias) og kopieres til alle "lange" " optegnelser, der svarer til det. Hvis nogen af værdierne ikke stemmer overens med filnavnet (for eksempel hvis filen blev omdøbt under en tidlig version af MS-DOS/Windows), opstår en forældreløs.
Et SFN-filalias med et langt navn består af en krop og om nødvendigt en digital "hale". Hvis filen har en filtypenavn, gemmes dens første tre tegn i aliaset. Det tilsvarende navn dannes ved at oversætte tegnene i det lange filnavn til OEM-kodningen, hvor alle mellemrum i det lange navn ignoreres, og tegn, der ikke kan oversættes i OEM eller forbudte i forbindelse med det korte navn, erstattes med en understregning "_". Cifferets hale "~n", hvor n = 1 ÷ 999999, føjes til aliasset, hvis det oprindeligt opnåede alias var i konflikt med navnet på en fil i samme mappe eller var længere end 8.3-standarden definerer, eller hvis et tegn, når ændring af kodning fandt ikke en OEM-modstykke og blev erstattet af en understregning. Således dannes aliaser som NEWFIL~1.DJV (LFN = New file for me.djvu). Filaliasing-skemaet er optimeret til hastighed og er derfor uforudsigeligt i detaljer.
Et filnavn, der ikke er et multiplum af 13 tegn, udfylder ikke fuldstændigt navnefelterne for LFN-poster i FAT-tabellen. I dette tilfælde afsluttes filnavnet kunstigt med et NUL-tegn (0x00), og overskydende bytes tilstoppes med enere (det vil sige med 0xFF-tegn).
For lange navne er længden af navnet begrænset til 255 tegn, NUL-separatoren ikke medregnet, og den fulde sti er begrænset til 260 tegn, inklusive NUL. Det lange navn tillader også brugen af seks specialtegn, der er forbudt i korte navne: +,; =[]
Hvis du forsøger at oprette en fil eller et bibliotek på en FAT32-diskenhed med et navn, der indeholder et sådant tegn, genereres der automatisk en LFN-post, uanset længden af filnavnet. En lignende proces opstår, når du opretter en fil/mappe med et navn, der indeholder ikke-ASCII-tegn.
Det er muligt, at bindetiketfilen ikke fysisk går forud for alle poster i bindet med lange navne (når bindet ikke har en etiket, eller etiketten blev tildelt efter en fil med et langt navn blev skrevet). Så vil volumenetiketten i FAT12/FAT16 ikke blive vist korrekt, da den vil blive taget fra den nærmeste LFN-record (fordi den også har VOLUME_ID attributten), og hvis du forsøger at ændre volumenetiketten, navnet på den tilsvarende fil faktisk vil blive overtrådt. Når du sletter en fil, der har tilknyttet LFN-poster, påvirkes sidstnævnte ikke og bliver forældreløse. Under den videre oprettelse af en ny fil kan den nævnte forældreløse fil fejlagtigt associeres med den, hvis kontrolsummerne for navnene på de gamle og nye filer stemmer overens med den anvendte kontrolsumberegningsalgoritme (ASCII-koden for det første tegn i filen alias forskydes cyklisk en smule til højre og koden for det næste tegn tilføjes osv. d) gør denne sandsynlighed ubetydelig.
Volumenformatering - indeksmarkørtabellen nulstilles, undtagen de tre første (FAT[0] og FAT[1], er reserveret, og FAT[2] indeholder en indgang, der svarer til volumenetiketten, eller, hvis den mangler, EOC-mærket) og registreringer af beskadigede klynger; rodbiblioteksposterne er sat til nul (undtagen volumenetikettefilen, hvis nogen), ellers påvirkes dataområdet ikke.
Filsletning - det første tegn i filposten og alle tilknyttede LFN-poster erstattes af koden 0xE5; de klynger, der er optaget af filen, er markeret som ledige i FAT-tabellen, men klyngerne i dataområdet påvirkes ikke.
Oprettelse af en fil eller et bibliotek med kommandoen "Ny" i kontekstmenuen - en filpost oprettes for en ny "tom" fil med et standardnavn (for eksempel "Ny mappe") og en størrelse bestemt af filtypen; selve filen, hvis den har en størrelse, der ikke er nul (hvilket er sandt for næsten alle "tomme" filer, undtagen mapper og tekstdokumenter), skrives til dataområdet i de klynger, der er allokeret til den; den tilsvarende klyngekæde oprettes i FAT-tabellen. Efter at have givet filen et gyldigt navn (ikke standard), markeres den oprindeligt oprettede filpost som slettet, og en ny oprettes.
Omdøbning af en fil - en ny post oprettes med et opdateret navn; den gamle post er markeret som slettet.
Lagring af en fil fra applikationen (ikke fra kommandolinjen) - der oprettes en post indeholdende alle felter undtagen størrelsen og indledende klynge af filen; efter at filen er gemt, oprettes en ny post, der indeholder alle felterne, og den gamle post slettes.
Kopiering af en fil - en identisk filpost oprettes på den nye placering (evt. bortset fra nogle tidsstempler, se ovenfor), den første ledige klynge allokeres til filen og indholdet af filen kopieres til den nye placering, mens der kopieres nuværende klynge, søger efter den næste ledige og udfylder FAT-tabellen .
Flytning af en fil (mellem forskellige volumener) - kopiering og sletning af filen fra dens oprindelige placering.
Filflytning (inden for volumen) - klyngekæden påvirkes ikke, filposten kopieres uændret til den nye mappe og slettes derefter fra den gamle.
Søgningen efter en ledig klynge i tabellen over indeksmarkører til tildeling til en ny fil starter generelt ikke fra begyndelsen af dataområdet (det vil sige fra klynge 2), men fra den sidste klynge, der er allokeret til en fil, antallet af som er gemt i FSInfo strukturen. Med andre ord, hvis fil 1 blev tildelt klynge 30, og fil 2 blev tildelt klynge 31, og derefter fil 1 blev slettet, så når en ny fil 3 er oprettet, vil den højst sandsynligt være fysisk placeret fra klynge 32.
Da FAT-systemet gemmer data om filer og data om ledig diskplads i den samme tabel, vil filskrivningsoperationen, som traditionelt består af to trin (tilføje den besatte blok til listen over optaget og slette den samme blok fra listen over frie), forekommer i FAT i én handling. På grund af dette har FAT-systemet en iboende fejltolerance, det vil sige, at en fejl (for eksempel strøm) på tidspunktet for en læse- eller skriveoperation i de fleste tilfælde ikke vil føre til ødelæggelse af filsystemet. Men i dette tilfælde taler vi om filsystemets integritet og ikke selve filerne.
| FAT12 | FAT16 | FAT32 | |
|---|---|---|---|
| Udvikler | Microsoft | ||
| Fuld titel | Filfordelingstabel | ||
| (12 bit version) | (16-bit version) | (32-bit version) | |
| Fremlagde | 1980 ( Microsoft Disk BASIC ) | August 1984 ( MS-DOS 3.00, afkortet) fuld - juli 1988, MS-DOS 4.0 [6] |
august 1996 (Windows 95 OSR 2) |
| Bind ID | 0x01 ( MBR ) | 0x04, 0x06, 0x0E (MBR) | 0x0B, 0x0C (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT ) |
| strukturer | |||
| Katalogindhold | Bord | ||
| Filplacering | Lineær liste | ||
| Dårlige blokke | Cluster tagging | ||
| Begrænsninger | |||
| filstørrelse | 32 MB _ | 2 GB _ | 4 GB |
| Antal klynger | 4084 | 65 524 | 268 435 445 (2 28 -12) |
| Filnavnets længde | 8,3 eller 255 tegn ved brug af LFN | ||
| Volumen størrelse | 2 MB (512 bytes pr. sektor)
32 MB (64 KB pr. klynge) |
2 GB 4 GB (64 KB pr. klynge, understøttes ikke overalt) |
2 TB 8 TB (32 KB pr. sektor) |
| Evner | |||
| Gemte datoer | Oprettelse, ændring, adgang | ||
| Datointerval | 1. januar 1980 - 31. december 2107 | ||
| Yderligere Information | Oprindeligt ikke understøttet | ||
| Fil attributter | Skrivebeskyttet, skjult, system, volumetiket, undermappe, arkiv | ||
| Differentiering af adgangsrettigheder | Ikke | ||
| Transparent kompression | Standalone hjælpeprogrammer ( Stacker , DoubleSpace , DriveSpace ) | ||
| Transparent kryptering | Tredjepartsværktøjer eller DOS-kloner | ||
Nogle algoritmer til at arbejde med FAT og VFAT er patenteret af Microsoft.
I USA om genovervejelse[ hvornår? ] blev det besluttet at annullere nogle af patenterne, men så blev det annulleret.
I oktober 2006 blev et patent på VFAT udstedt af European Patent Office [7] annulleret i Tyskland for åbenbarhedens skyld .
Med tiden blev FAT meget brugt i forskellige enheder for kompatibilitet mellem DOS, Windows, OS/2, Linux. Microsoft har ikke vist nogen hensigt om at tvinge dem til at licensere[ præciser ] [8] .
I februar 2009 sagsøgte Microsoft TomTom , en producent af Linux -baserede bilnavigationssystemer , for patentkrænkelse [9] .
Ifølge Jeremy Ellison[ præciser ] Microsofts mål er at præsentere forskellige virksomheder for et valg: indgå en patentbeskyttelsesaftale med Microsoft (som f.eks. Novell indgik med det i november 2006), og derved overtræde GNU GPL og gøre det umuligt for dem selv at bruge Linux , eller ikke indgå en sådan aftale og blive anklaget for at krænke patenter, hvis beskyttelse ydes ved indgåelsen af dem på betingelse af hemmeligholdelse [10] [11] .
I marts 2009 indgav TomTom et modkrav for patentkrænkelse [12] .
| OS/2 - komponenter og API'er | |
|---|---|
| Hoved | |
Management Services | |
| Spil |
|
| OS kerne | |
| Filsystemer | |
| Grafik undersystem |
|
| Objektmodel | SOM
|
| Kompatibilitet |
|
| Filsystemer ( liste , sammenligning ) | |||||||
|---|---|---|---|---|---|---|---|
| Disk |
| ||||||
| Distribueret (netværk) | |||||||
| Særlig |
| ||||||
| Ecma internationale standarder | |
|---|---|