File Allocation Table (FAT) ist der Name einer Computerdateisystemarchitektur und eine Familie von Industriestandarddateisystemen, die es verwerten.

Das FETTE Dateisystem ist noch robust technisch relativ einfach. Es bietet vernünftig gute Leistung sogar in Leichtgewichtsdurchführungen an und wird deshalb weit angenommen und durch eigentlich alle vorhandenen Betriebssysteme für Personalcomputer unterstützt. Das macht es ein gut passendes Format für den Datenaustausch zwischen Computern und Geräten fast jedes Typs und Alters vom Anfang der 1980er Jahre bislang.

Ursprünglich entworfen gegen Ende der 1970er Jahre für den Gebrauch auf Disketten wurde es bald angepasst und fast allgemein auf Festplatten überall in DOS und Zeitalter des Windows 9x seit zwei Jahrzehnten verwendet. Mit der Einführung von stärkeren Computern und Betriebssystemen hat sein Gebrauch auf Festplatten seitdem angefangen sich zu neigen, aber sie setzt fort, auf vielen Computersystemen verwendet zu werden.

Heute werden FETTE Dateisysteme noch auf Disketten, Halbleiterspeicherkarten, Blitz-Speicherkarten, und auf vielen tragbaren und eingebetteten Geräten allgemein gefunden.

Der Name des Dateisystems entsteht aus dem prominenten Gebrauch des Systems der Datei eines Index-Tisches, des FETTES, das statisch zur Zeit der Formatierung zugeteilt ist. Der Tisch enthält Einträge für jede Traube, ein aneinander grenzendes Gebiet der Plattenlagerung. Jeder Zugang enthält entweder die Zahl der folgenden Traube in der Datei, oder ein Anschreiber-Anzeigen-Ende der Datei, des unbenutzten Speicherplatzes, oder spezielle reservierte Bereiche der Platte. Das Wurzeldateiverzeichnis der Platte enthält die Zahl der ersten Traube; das Betriebssystem kann dann den FETTEN Tisch überqueren, die Traube-Zahl jedes aufeinander folgenden Teils der Plattendatei als eine Traube-Kette nachschlagend, bis das Ende der Datei erreicht wird.

Da sich Laufwerke entwickelt haben, hat die maximale Zahl von Trauben bedeutsam zugenommen, und so hat die Zahl von Bit gepflegt sich zu identifizieren, ist jede Traube gewachsen. Die aufeinander folgenden Hauptversionen des FETTEN Formats werden nach der Zahl von Tabellenelement-Bit genannt: 12 (FAT12), 16 (FAT16), und 32 (FAT32). Jede dieser Varianten ist noch im Gebrauch. Der FETTE Standard ist auch auf andere Weisen ausgebreitet worden, während man allgemein rückwärts gerichtete Vereinbarkeit mit der vorhandenen Software bewahrt.

Übersicht

Gebrauch

Das FETTE Dateisystem ist noch robust einfach. Es bietet angemessene Leistung sogar in Leichtgewichtsdurchführungen an und wird deshalb weit angenommen und durch eigentlich alle vorhandenen Betriebssysteme für Personalcomputer sowie einige Hauscomputer und eingebettete Systeme unterstützt. Das macht es ein nützliches Format für Halbleiterspeicherkarten und eine günstige Weise, Daten zwischen Betriebssystemen zu teilen.

FETTE Dateisysteme sind das Verzug-Dateisystem für absetzbare Medien (mit Ausnahme von CDs und DVDs), und weil solcher auf Disketten, Floppy Superdiscs, Gedächtnis und Blitz-Speicherkarten oder USB-Blitz-Laufwerken allgemein gefunden werden und durch die meisten tragbaren Geräte wie PDAs, Digitalkameras, Kameras, Mediaspieler oder Mobiltelefone unterstützt werden. Während FAT12 auf Disketten allgegenwärtig ist, werden FAT16 und FAT32 normalerweise auf den größeren Medien gefunden.

FETT wurde auch auf Festplatten überall in DOS und Zeitalter des Windows 9x allgemein verwendet, aber sein Gebrauch auf Festplatten hat sich seit der Einführung von Windows XP geneigt, der in erster Linie den neueren NTFS verwendet. FETT wird noch in Festplatten verwendet, die angenommen sind, durch vielfache Betriebssysteme, solcher als in geteiltem Windows und Umgebungen von Linux verwendet zu werden.

Wegen des weit verbreiteten Gebrauches von Fett-formatierten Medien haben viele Betriebssysteme Unterstützung für FETT, und nachher VFAT und FAT32 durch offizielle oder Drittdateisystemdressierer zur Verfügung gestellt. Zum Beispiel stellen Linux, FreeBSD, BeOS und JNode integrierte Unterstützung für FETT zur Verfügung.

Mac OS 9 und Mac OS X unterstützt auch FETTE Dateisysteme auf Volumina außer der Stiefelplatte. AmigaOS unterstützt FETT durch das Dateisystem von CrossDOS.

Zu vielen Zwecken ist das NTFS Dateisystem als FETT in Bezug auf Eigenschaften und Zuverlässigkeit höher; seine Hauptnachteile sind die Größe oben für kleine Volumina und die sehr beschränkte Unterstützung durch etwas anderes als die NT-basierten Versionen von Windows, da die genaue Spezifizierung ein Geschäftsgeheimnis des Microsofts ist. Die Verfügbarkeit von NTFS-3G seit der Mitte 2006 hat zu viel geführt hat NTFS-Unterstützung in Unix ähnlichen Betriebssystemen verbessert, beträchtlich diese Sorge erleichternd. Es ist noch immer nicht möglich, NTFS in EINEM DOS ähnlichen Betriebssystemen ohne Drittfahrer zu verwenden, der es der Reihe nach schwierig macht, einen DOS-Floppy Disc zu Wiederherstellungszwecken zu verwenden. Microsoft hat eine Wiederherstellungskonsole zur Verfügung gestellt, um um dieses Problem zu arbeiten, aber für Sicherheitsgründe hat es streng beschränkt, was durch die Wiederherstellungskonsole standardmäßig getan werden konnte. Die Bewegung von Wiederherstellungsdienstprogrammen, um CDs zu starten, die auf BartPE oder Linux (mit NTFS-3G) gestützt sind, frisst schließlich diesen Nachteil weg.

FETT hat eine lange Geschichte (mehr als drei Jahrzehnte) vom Gebrauch auf Arbeitsflächen und tragbaren Computern, und es wird oft in eingebetteten Lösungen verwendet. Es setzt fort, das weit verbreitetste Dateisystem weltweit zu sein.

Für Disketten ist FETT als ECMA-107 und ISO/IEC 9293:1994 standardisiert worden (ISO 9293:1987 ersetzend). Diese Standards bedecken FAT12 und FAT16 mit nur der kurzen 8.3 Dateinamenunterstützung; lange Dateinamen mit VFAT werden teilweise patentiert.

Historische Evolution

Dateisystemtypen

Ursprüngliches 8-Bit-FETT

Entworfen und codiert von Marc McDonald hat Microsoft Stand-alone Disk BASIC das FETT 1977 mit 8-Bit-Tabellenelementen eingeführt, die für 8 Bit von NCR 8080 Dateisystem erzeugt sind. Das FETT, das während einer einer Reihe von Diskussionen zwischen McDonald und Bill Gates geboren ist, wurde in einer eigenständigen Version von Microsoft BASIC für die 8086 verwendet steuern in 1979 und schließlich in der M DOS Betriebssystem bei. Die Version von Microsoft Disk BASIC hat drei FETTE unterstützt.

FAT12

1980, während er das FETTE Konzept des Microsofts für Seattler 86-DOS-Computerprodukte geliehen hat, hat Tim Paterson die Tabellenelemente zu 12 Bit für seine Durchführung von FAT12 erweitert, wohingegen der 8-Bit-Dateisystemvorgänger durch den 86-DOS-nicht unterstützt wurde. Später 1981 86-DOS-entwickelt ins MS-DOS des Microsofts und IBM PC DOS.

Ursprünglich entworfen als ein Dateisystem für Disketten hat FAT12 12-Bit-Einträge für die Traube-Adressen im FETT verwendet, das nicht nur die maximale allgemein mögliche Zählung von Datentrauben zu 4078 beschränkt hat (für Datentrauben dazu; in der C-Notation für hexadecimal Zahlen) oder in einigen kontrollierten Drehbüchern sogar bis zu 4084 (für Datentrauben zu), aber gemachte FETTE mit den 8-bit- und 16-Bit-Registern des PCs heikle Manipulation. (NB. Während MS-DOS und PC-DOS bis zu 4084 Datentrauben auf FAT12 Volumina im Allgemeinen unterstützen, wird Traube-Wert als zusätzlicher Anschreiber des Endes der Kette auf jedem FAT12 Volumen seit MS-DOS/PC DOS 3.3 behandelt, deshalb die maximale praktische Zahl von Datentrauben zu 4078 zu Vereinbarkeitszwecken mit diesen Betriebssystemen einschränkend.)

Die Größe der Platte wurde versorgt und hat als eine 16-Bit-Zählung von Sektoren gerechnet, die die Größe auf 32 für eine logische Sektor-Größe von 512 Bytes beschränkt haben. FAT12 wurde von mehreren Herstellern mit verschiedenen physischen Formaten verwendet, aber eine typische Diskette war zurzeit (130 Mm) 5.25-zöllig, 40 Spuren mit 8 Sektoren pro Spur einseitig bespannt, auf eine Kapazität 160 sowohl für die Systemgebiete als auch für Dateien hinauslaufend. Die FAT12 Beschränkungen haben diese Kapazität durch einen Faktor zehn oder mehr überschritten. (NB. Die 32 Grenze wurde später mit logischen sectored FETTEN mit logischen Sektor-Größen überlistet, die größer sind als 512 Bytes in einigen OEM-Versionen des MS-DOS 3.x, und es wurde weiter mit DOS 3.31 gehoben, der 32-Bit-Sektor-Zahlen unterstützt hat, aber seldomly hat wegen der Verfügbarkeit von FAT16B verwendet.)

Durch die Tagung wurden alle Kontrollstrukturen organisiert, um innerhalb der ersten Spur zu passen, so Hauptbewegung während des gelesenen vermeidend und Operationen zu schreiben, obwohl sich das abhängig vom Hersteller und physischen Format der Platte geändert hat. Eine Beschränkung, die bis viel später nicht gerichtet wurde (mit FAT32) war, dass jeder schlechte Sektor im Kontrollstruktur-Gebiet, Spur 0, die Platte davon abhalten konnte, verwendbar zu sein. Das DOS-Formatierungswerkzeug hat solche Platten völlig zurückgewiesen. Schlechten Sektoren wurde nur im Dateidatengebiet erlaubt und wurde mit dem vorbestellten Wert im FETT gekennzeichnet. Sie haben das komplette gemacht, das unbrauchbare Traube enthält.

Während drei unterstützte 86-DOS-Platte (250.25, 500.5 und 1232 mit Mediadeskriptor-Bytes und) auf 8-zölligen (200 Mm) schlaffen Laufwerken formatiert, hat IBM PC DOS 1.0, der mit ursprünglichem IBM Personal Computer 1981 befreit ist, nur ein schlaffe 8-Sektoren-Format mit einer formatierten Kapazität 160 (Mediadeskriptor-Byte) für einseitig bespannte 5.25-zöllige schlaffe Laufwerke und PC-DOS 1.1 hinzugefügte Unterstützung für ein zweiseitiges Format mit 320 (Mediadeskriptor-Byte) unterstützt. PC-DOS 2.0 hat Unterstützung für schlaffe 9-Sektoren-Formate mit 180 (Mediadeskriptor-Byte) und 360 (Mediadeskriptor-Byte) eingeführt.

PC-DOS 1.0 Verzeichniseinträge hat nur ein Datum, das letzte modifizierte Datum eingeschlossen. PC-DOS 1.1 hat das letzte modifizierte Mal beigetragen. PC-DOS 1.x haben Dateiattribute ein verborgenes Bit eingeschlossen, und System hat mit den restlichen unbestimmten sechs Bit gebissen. In dieser Zeit hat DOS kein hierarchisches Dateisystem unterstützt, das noch annehmbar war, vorausgesetzt, dass die Zahl von Dateien auf einer Platte normalerweise nicht mehr als einige Dutzend war.

Der PC XT war der erste PC mit einer Festplatte von IBM und PC-DOS 2.0, hat diese Festplatte mit FAT12 (Mediadeskriptor-Byte) unterstützt. Die feste Annahme von 8 Sektoren pro Trauben auf Festplatten hat praktisch die maximale Teilungsgröße auf 16 für 512-Byte-Sektoren und 4 Trauben beschränkt.

BIOS Parameter Block (BPB) wurde mit PC-DOS 2.0 ebenso eingeführt, und diese Version hat auch read-only-, Archiv, Volumen-Etikett und Verzeichnisattribut-Bit für hierarchische Unterverzeichnisse beigetragen.

MS-DOS 3.0 hat Unterstützung für dichte 1.2 5.25-zöllige Disketten eingeführt (Mediadeskriptor-Byte), der namentlich 15 Sektoren pro Spur, folglich mehr Raum für die FETTE hatte.

FAT12 bleibt im Gebrauch auf allen allgemeinen Disketten, einschließlich 1.44 und spätere 2.88 Platten (Mediadeskriptor-Byte).

Anfänglicher FAT16

1984 hat IBM den PC DARAN veröffentlicht, der eine 20 Festplatte gezeigt hat. Microsoft hat MS-DOS 3.0 in der Parallele eingeführt. Traube-Adressen wurden zu 16 Bit vergrößert, bis zu 65,524 Trauben pro Volumen und folglich viel größere Dateisystemgrößen mindestens in der Theorie berücksichtigend. Jedoch, die maximale mögliche Zahl von Sektoren und dem Maximum (Teilung, aber nicht Platte) Größe 32 hat sich nicht geändert. Deshalb, obwohl Traube-Adressen 16 Bit waren, war dieses Format nicht, was heute als FAT16 allgemein verstanden wird.

Ein Teilungstyp zeigt diese Form von FAT16 mit weniger als 65536 Sektoren (weniger als 32 für die Sektor-Größe 512) an.

Mit der anfänglichen Durchführung von FAT16 nicht wirklich das Sorgen für größere Teilungsgrößen als FAT12 sollte der frühe Vorteil von FAT16 den Gebrauch von kleineren Trauben ermöglichen, Plattengebrauch effizienter, besonders für Dateien mehrere hundert Bytes in der Größe machend, die zurzeit viel üblicher waren.

MS-DOS 2.x Festplatten, die größer sind als 15, ist mit späteren Versionen des MS-DOS unvereinbar. Eine 20 Festplatte, die unter dem MS-DOS 3.0 formatiert ist, war durch das ältere MS-DOS 2.0 nicht zugänglich, weil MS-DOS 2.0 Version 3.0's FAT16 nicht unterstützt hat. MS-DOS 3.0 konnte noch auf MS-DOS 2.0 Stil 8 - Traube-Teilungen unter 15 zugreifen.

Logisches sectored FETT

Als Festplatten größer und der FAT12 und die FAT16 Dateisystemdurchführung im MS-DOS / gewachsen sind, hat PC-DOS Mittel nicht zur Verfügung gestellt, die Extralagerung auszunutzen, mehrere Hersteller haben ihre eigenen FETTEN Varianten entwickelt, um das Problem in ihren MS-DOS-OEM-Problemen zu richten.

Einige Verkäufer (AST und NEC) haben acht, statt der normalen vier unterstützt, primäre Teilungseinträge in ihrer Gewohnheit haben Master Boot Record (MBR) erweitert, und sie haben MS-DOS angepasst, um mehr als eine einzelne primäre Teilung zu verwenden.

Andere Verkäufer haben um die Volumen-Größe-Grenzen gearbeitet, die durch die 16-Bit-Sektor-Einträge und arithmetics festgesetzt sind, indem sie die Größe der Sektoren das Dateisystem vergrößern, befasst, dadurch Dimensionen vernichtend.

Diese so genannten logischen Sektoren waren (bis zu 8192 Bytes) größer als die physische Sektor-Größe (noch normalerweise 512 Bytes), wie erwartet, durch die INTERNE NUMMER des ROMS-BIOS 13. oder die Laufwerk-Hardware. DOS-BIOS oder System BIOS würden dann vielfache physische Sektoren in logische Sektoren für das Dateisystem verbinden, um damit zu arbeiten.

Diese Änderungen waren zur Dateisystemdurchführung im DOS-Kern durchsichtig, seitdem auf diesem Abstraktionsniveau sind Volumina eine Reihe logisch addressable Sektoren (mit dem logischen Sektor 0 anfangend), unabhängig der physischen Position des Volumens auf dem physischen Medium und seiner Geometrie. Zu Grunde liegendes DOS-BIOS hat diese logischen Sektoren in physische Sektoren gemäß dem Verteilen der Information und der physischen Geometrie des Laufwerkes übersetzt.

Der Nachteil dieser Annäherung war eine weniger speichereffiziente Sektor-Pufferung und deblocking in DOS-BIOS, dadurch einen vergrößerten Speicherfußabdruck für die DOS-Datenstrukturen verursachend.

Seitdem ältere DOS-Versionen nicht flexibel genug waren, um mit dieser logischen Geometrie zu arbeiten, mussten die OEM neue Teilungspersonalausweise für ihre FETTEN Varianten einführen, um sie vor Standardproblemen des MS-DOS und PC-DOS zu verbergen. Bekannte Teilungspersonalausweise für logische sectored FETTE schließen ein: (Kommodore-MS-DOS 3.x), (Spitzen-MS-DOS 3.x), (AST MS-DOS 3.x), (NEC MS-DOS 3.30), (AT&T MS-DOS 3.x), (MS-DOS von Tandy), (Sperry ES MS-DOS 3.x, Unisys MS-DOS 3.3 - auch verwendet durch Digitalforschungs-DOS Plus 2.1).

Während umgangssprachlich und suboptimal diese FETTEN Varianten gemäß den Spezifizierungen des Dateisystems selbst vollkommen gültig sind. Deshalb, selbst wenn Verzug-Probleme des MS-DOS und PC-DOS nicht im Stande gewesen sind, mit ihnen fertig zu werden, können die meisten dieser mit dem Verkäufer spezifischen FAT12 und FAT16 Varianten durch flexiblere Dateisystemdurchführungen in Betriebssystemen wie DR-DOS, einfach durch das Ändern des Teilungspersonalausweises zu einem der anerkannten Typen bestiegen werden. Außerdem, wenn sie nicht mehr durch ihre ursprünglichen Betriebssysteme anerkannt werden müssen, können vorhandene Teilungen in FAT12 und FAT16 Volumina "umgewandelt" werden, die mit Versionen von MS-DOS/PC DOS wie 5.0-6.3 mehr entgegenkommend sind, die Sektor-Größen nicht unterstützen, die von 512 Bytes, durch die Schaltung auf einen BPB mit 32-Bit-Zugang für die Zahl von Sektoren, wie eingeführt, seit DOS 3.31 verschieden sind (sieh FAT16B unten), das Behalten der Traube-Größe und das Reduzieren der logischen Sektor-Größe im BPB unten zu 512 Bytes, während sie zur gleichen Zeit die Zählungen von logischen Sektoren pro Traube vergrößert haben, haben logische Sektoren, logische Gesamtsektoren und logische Sektoren pro FETT durch denselben Faktor vorbestellt.

Eine parallele Entwicklung im MS-DOS / PC-DOS, das eine Zunahme in der maximalen möglichen FETTEN Größe erlaubt hat, war die Einführung von vielfachen FETTEN Teilungen auf einer Festplatte. Um den Gebrauch von FETTEREN Teilungen auf eine vereinbare Weise zu erlauben, wurde ein neuer Teilungstyp in PC-DOS 3.2 (1986) eingeführt, die verlängerte Teilung (EBR), der ein Behälter für eine zusätzliche Teilung ist, hat logischen Laufwerk genannt. Seit PC-DOS 3.3 (April 1987) gibt es einen anderen, fakultative verlängerte Teilung, die den folgenden logischen Laufwerk und so weiter enthält. Der MBR einer Festplatte kann entweder bis zu vier primäre Teilungen oder eine verlängerte Teilung zusätzlich zu bis zu drei primären Teilungen definieren.

End-FAT16

Schließlich im November 1987 hat MS-DOS von Compaq 3.31 (eine modifizierte OEM-Version des MS-DOS 3.3 veröffentlichte durch Compaq mit ihren Maschinen) eingeführt, was einfach heute als das FAT16-Format mit der Vergrößerung der 16-Bit-Plattensektor-Zählung zu 32 Bit im BPB bekannt ist.

Obwohl die Änderungen auf der Platte gering waren, musste der komplette DOS-Plattenfahrer umgewandelt werden, um 32-Bit-Sektor-Zahlen, eine durch die Tatsache komplizierte Aufgabe zu verwenden, dass sie auf 16-Bit-Zusammenbau-Sprache geschrieben wurde.

Das Ergebnis wurde DOS 3.31 Großes Dateisystem am Anfang genannt. Das DSKPROBE Werkzeug des Microsofts kennzeichnet Typ als BigFAT, wohingegen einige ältere Versionen von FDISK es als BIGDOS beschrieben haben. Es ist auch bekannt als FAT16B.

Seitdem ältere Versionen von DOS mit mehr als 65535 Sektoren nicht fertig werden konnten, war es auch notwendig, einen neuen Teilungstyp für dieses Format einzuführen, es vor Vordos 3.31 Probleme von DOS zu verbergen. Während die ursprüngliche Form von FAT16 mit weniger als 65536 Sektoren einen Teilungstyp hatte, zeigt ein Typ 65536 oder mehr Sektoren an. Zusätzlich zu diesem geänderten Teilungspersonalausweis und der Vergrößerung der Plattenfahrer Format, um fertig zu werden, sind mehr als 65535, der einzige weitere Unterschied zwischen dem ursprünglichen FAT16 und dem FAT16B-Format der Gebrauch des neueren BPB mit 32-Bit-Sektor-Zugang, so dass neuere Betriebssysteme auch dem ursprünglichen FAT16-Format ohne irgendwelche notwendigen Änderungen gewachsen sein können. Wenn Teilungen, die durch Vordos zu verwenden sind, das 3.31 Probleme von DOS durch moderne Werkzeuge, die einzigen Kriterien geschaffen werden müssen, die theoretisch notwendig sind, um zu entsprechen, eine Sektor-Zählung von weniger als 65536 und der Gebrauch des alten Teilungspersonalausweises sind. In der Praxis, jedoch, sollten Typ und Teilungen nicht außerhalb der ersten 32 der Platte, wegen anderer Beschränkungen im MS-DOS 2.x physisch gelegen werden, der mit ihnen sonst nicht fertig werden konnte.

1988 ist die FAT16B Verbesserung allgemein verfügbarer durch DR DOS 3.31, MS-DOS 4.0 und OS/2 1.1 geworden. Die Grenze auf der Teilungsgröße wurde von der unterzeichneten Zählung der 8 Bit von Sektoren pro Traube diktiert, die ursprünglich ein Maximum power-two Wert von 64 hatte. Mit der Standardfestplatte-Sektor-Größe von 512 Bytes gibt das ein Maximum von 32 Traube-Größe, dadurch das "endgültige" Limit für die FAT16 Teilungsgröße an 2 für die Sektor-Größe 512 stellend. Auf mit dem Magnetzünder optischen Medien, die 1 oder 2 Sektoren statt 0.5 haben können, ist diese Größe-Grenze proportional größer.

Viel später hat Windows NT die maximale Traube-Größe zu 64, durch das Betrachten der Zählung der Sektoren pro Traube als nicht unterzeichnet vergrößert. Jedoch war das resultierende Format mit jeder anderen FETTEN Durchführung der Zeit nicht vereinbar, und es hat größere innere Zersplitterung erzeugt. Windows 98, SE und ICH haben auch das unterstützte Lesen und Schreiben dieser Variante, aber seiner Plattendienstprogramme damit nicht gearbeitet, und einige FCB Dienstleistungen sind für solche Volumina nicht verfügbar. Das trägt zu einer verwirrenden Vereinbarkeitssituation bei.

Vor 1995 haben Versionen von DOS auf die Platte über CHS das Wenden nur zugegriffen. Als MS-DOS 7.0 / Windows 95 LBA Plattenzugang eingeführt hat, konnten Teilungen anfangen, außerhalb des ersten ca physisch gelegen zu werden. 8 dieser Platte und dadurch aus der Reichweite des traditionellen CHS das Wenden des Schemas. Teilungen teilweise oder völlig gelegen außer der CHS Barriere mussten deshalb vor non-LBA-enabled Betriebssysteme durch das Verwenden des neuen partion Typs im Teilungstisch stattdessen verborgen werden. FAT16 Teilungen mit diesem Teilungstyp werden auch FAT16X genannt. Der einzige Unterschied, im Vergleich zu vorherigen FAT16 Teilungen, ist die Tatsache, dass einige CHS-zusammenhängende Geometrie-Einträge in der BPB-Aufzeichnung, nämlich die Zahl von Sektoren pro Spur und die Zahl von Köpfen, keine oder irreführenden Werte enthalten können und nicht verwendet werden sollten.

Die Zahl von Wurzelverzeichniseinträgen, die für FAT12 und FAT16 verfügbar sind, wird bestimmt, wenn das Volumen formatiert wird, und in einem 16-Bit-Feld versorgt wird. Für eine gegebene Zahl und Sektor-Größe ist die Zahl von Wurzelverzeichnissektoren, und wird normalerweise gewählt, um diese Sektoren zu füllen, d. h.. FAT12 und FAT16 Medien verwenden normalerweise 512 Wurzelverzeichniseinträge auf nichtschlaffen Medien. Einige Drittwerkzeuge, wie mkdosfs, erlauben dem Benutzer, diese Parameter aufzustellen.

FAT32

Um die Größe-Grenze von FAT16 zu überwinden, während er zur gleichen Zeit DOS echten Weise-Code erlaubt, um das Format zu behandeln, und ohne verfügbares herkömmliches Gedächtnis unnötigerweise zu reduzieren, hat Microsoft die Traube-Größe immer wieder ausgebreitet, die neue Revision FAT32 nennend. Traube-Werte werden durch 32-Bit-Zahlen vertreten, von denen 28 Bit verwendet werden, um die Traube-Zahl zu halten. Der Stiefelsektor verwendet ein 32-Bit-Feld für die Sektor-Zählung, die FAT32 Volumen-Größe auf 2 für die Sektor-Größe von 512 Bytes und 16 für die Sektor-Größe von 4,096 Bytes beschränkend.

FAT32 wurde mit dem MS-DOS 7.1 / Windows 95 OSR2 1996 eingeführt, obwohl Wiederformatierung erforderlich war, um es, und DriveSpace 3 zu verwenden (die Version, die mit Windows 95 OSR2 gekommen ist und Windows 98) es nie unterstützt hat. Windows 98 hat ein Dienstprogramm eingeführt, um vorhandene Festplatten von FAT16 bis FAT32 ohne Verlust von Daten umzuwandeln.

In der Linie des Windows NT ist die heimische Unterstützung für FAT32 in Windows 2000 angekommen. Ein freier FAT32 Fahrer für Windows NT 4.0 war von Winternals, einer von Microsoft später erworbenen Gesellschaft verfügbar. Seit dem Erwerb ist der Fahrer nicht mehr offiziell verfügbar.

Seit 1998 konnte Krater dynamisch loadable DRFAT32 Fahrer verwendet werden, um FAT32-Unterstützung in DR-DOS zu ermöglichen. Die erste Version von DR-DOS, um FAT32 und LBA Zugang heimisch zu unterstützen, war OEM-DR-DOS 7.04 1999. Dass dasselbe Jahr IMS hat heimische FAT32-Unterstützung mit ECHTEN/32 7.90 und IBM 4690 OS eingeführt, FAT32-Unterstützung mit der Version 2 hinzugefügt hat. Vorn hat Software einem anderen dynamisch loadable FAT32.EXE Fahrer für DR-DOS 7.03 mit Nero Brennendes ROM 2004 zur Verfügung gestellt. IBM PC DOS hat heimische FAT32-Unterstützung mit OEM-PC-DOS 7.10 2003 eingeführt.

Die maximale mögliche Größe für eine Datei auf einem FAT32 Volumen ist 4 minus 1 Byte oder 4,294,967,295 (21) Bytes. Diese Grenze ist eine Folge des Dateilänge-Zugangs im Verzeichnistisch und würde auch riesige FAT16 Teilungen mit einer genügend Sektor-Größe betreffen. Videoanwendungen, große Datenbanken und eine andere Software überschreiten leicht diese Grenze.

Das offene FETT + schlägt Spezifizierung vor, wie man größere Dateien bis zu 256 minus 1 Byte oder 274,877,906,943 (21) Bytes auf ein bisschen modifiziertem und sonst umgekehrt vereinbare FAT32 Volumina versorgt, aber eine Gefahr auferlegt, dass Plattenwerkzeuge oder FAT32 dieser Erweiterung nicht bewusste Durchführungen stutzen oder Dateien löschen können, die die normale FAT32 Dateigröße-Grenze überschreiten. Außerdem wird die Unterstützung für FAT32 + (und FAT16 +) auf einige Versionen von DR-DOS und FreeDOS und nicht verfügbar in der Hauptströmung Betriebssysteme bis jetzt beschränkt. (Diese Erweiterung ist mit der Auswahl des FAT32 kritisch unvereinbar. IFS Methode, OS/2 zu versorgen, hat Attribute auf FAT32 Volumina erweitert.)

Als mit vorherigen Dateisystemen schließt das Design des FAT32 Dateisystems direkte eingebaute Unterstützung für lange Dateinamen nicht ein, aber FAT32 Volumina können VFAT lange Dateinamen zusätzlich zu kurzen Dateinamen auf genau dieselbe Weise wie VFAT fakultativ halten lange Dateinamen sind für FAT12 und FAT16 Volumina fakultativ durchgeführt worden.

Zwei Teilungstypen sind für FAT32 Teilungen vorbestellt worden, und. Der letzte Typ wird auch FAT32X genannt, um Gebrauch des LBA Plattenzugangs statt CHS anzuzeigen. Auf solchen Teilungen können einige CHS-zusammenhängende Geometrie-Einträge in der EBPB-Aufzeichnung, nämlich die Zahl von Sektoren pro Spur und die Zahl von Köpfen, keine oder irreführenden Werte enthalten und sollten nicht verwendet werden.

Ein freier Windows-basierter FAT32 formatter ist verfügbar, der viele der willkürlichen von Microsoft auferlegten Beschränkungen überwindet.

Erweiterungen

Verlängerte Attribute

OS/2 hängt schwer von verlängerten Attributen (EAs) ab und versorgt sie in einer verborgenen Datei genannt "" im Wurzelverzeichnis des FAT12 oder FAT16 Volumens. Diese Datei wird durch zwei vorher vorbestellte Bytes in der Datei (oder Verzeichnis) Verzeichniszugang am Ausgleich mit einem Inhaltsverzeichnis versehen. Im FAT32-Format halten diese Bytes die oberen 16 Bit der Starttraube-Zahl der Datei oder des Verzeichnisses, folglich es unmöglich machend, OS/2 EAs auf FAT32 mit dieser Methode zu versorgen.

Jedoch, der FAT32 Drittfahrer des Installable-Dateisystems (IFS) FAT32. IFS Version 0.70 und höher durch Henk Kelder & Netlabs für OS/2 und EComStation-Läden hat Attribute in Extradateien mit Dateinamen erweitert, die die Schnur "" haben, die am regelmäßigen Dateinamen der Datei angehangen ist, der sie gehören. Der Fahrer verwertet auch das Byte am Ausgleich in Verzeichniseinträgen, um ein spezielles Zeichen-Byte zu versorgen, das die Anwesenheit verlängerter Attribute anzeigt, um zu helfen, Dinge zu beschleunigen. (Diese Erweiterung ist mit dem FAT32 + Methode kritisch unvereinbar, Dateien zu versorgen, die größer sind als 4 minus 1 auf FAT32 Volumina.)

Verlängerte Attribute sind über den Arbeitsplatz Arbeitsfläche von Shell, durch REXX Schriften und viele System GUI und Dienstprogramme der Befehl-Linie (solcher als 4OS2) zugänglich.

Um sein OS/2 Subsystem anzupassen, unterstützt Windows NT das Berühren von verlängerten Attributen in HPFS, NTFS, FAT12 und FAT16. Es versorgt EAs auf FAT12, FAT16 und HPFS, der genau dasselbe Schema wie OS/2 verwendet, aber unterstützt keine andere Art von ANZEIGEN, wie NTFS Volumina festgehalten hat. Das Versuchen, eine Datei mit irgendwelchen ANZEIGEN außer EAs von einem NTFS Volumen bis ein FETT oder HPFS Volumen zu kopieren, gibt eine Warnungsnachricht mit den Namen des ADSs, der verloren wird. Es unterstützt den FAT32 nicht. IFS Methode, EAs auf FAT32 Volumina zu versorgen.

Windows 2000 handelt vorwärts genau als Windows NT, außer dass es EAs ignoriert, wenn es zu FAT32 ohne jede Warnung kopiert (aber zeigt die Warnung für anderen ADSs, wie "Finder-Info von Macintosh" und "Quellengabel von Macintosh").

Cygwin verwendet "" Dateien ebenso.

Lange Dateinamen

Eine der Benutzererfahrungsabsichten für die Entwerfer von Windows 95 war die Fähigkeit, lange Dateinamen zu verwenden (LFNs — bis zu 255 UTF-16-Code weist lange hin), zusätzlich zu klassischen 8.3 Dateinamen (SFNs). Für die rückwärts gerichtete Vereinbarkeit wurden LFNs als eine fakultative Erweiterung oben auf den vorhandenen FETTEN Dateisystemaufbauten mit einem workaround in der Weise durchgeführt, wie Verzeichniseinträge (sieh unten) angelegt werden.

Diese durchsichtige Methode, lange Dateinamen in den vorhandenen FETTEN Dateisystemen zu versorgen, ohne ihre Datenstrukturen zu verändern, ist gewöhnlich als VFAT (für "Virtuelles FETT") nach dem Fahrer des virtuellen Geräts von Windows 95 bekannt.

In Windows NT, Unterstützung für VFAT haben lange Dateinamen von der Version 3.5 angefangen.

Nicht VFAT-ermöglicht Betriebssysteme kann noch auf die Dateien unter ihrem kurzen Dateiname-Decknamen ohne Beschränkungen jedoch zugreifen, die verbundenen langen Dateinamen können verloren werden, wenn Dateien mit langen Dateinamen unter nicht VFAT-bewusste Betriebssysteme kopiert werden.

OS/2 hat lange Dateinamenunterstützung zu FETTEN verlängerten Verwenden-Attributen (EA) vor der Einführung von VFAT hinzugefügt; so sind VFAT lange Dateinamen sind für OS/2 und EA lange Dateinamen unsichtbar, für Windows unsichtbar.

Um javanische Anwendungen zu unterstützen, hat die mit Sitz in FlexOS Version 2 von IBM 4690 OS ihre eigene Architektur des virtuellen Dateisystems (VFS) eingeführt, um lange Dateinamen im FETTEN Dateisystem auf eine umgekehrt vereinbare Mode zu versorgen. Wenn ermöglicht, sind die virtuellen Dateinamen (VFN) laut getrennter logischer Laufwerk-Briefe verfügbar, wohingegen die echten Dateinamen (RFN) verfügbar laut der ursprünglichen Laufwerk-Briefe bleiben.

Gabeln und abwechselnde Datenströme

Das FETTE Dateisystem selbst wird nicht entworfen, für Alternate Data Streams (ADS) zu unterstützen, aber einige Betriebssysteme, die von ihnen schwer abhängen, haben verschiedene Methoden ausgedacht, um sie in FETTEN Laufwerken zu behandeln. Solche Methoden entweder versorgen die Zusatzinformation in Extradateien und Verzeichnissen (Mac OS), oder geben neue Semantik vorher unbenutzten Feldern der FETTEN Datenstrukturen auf der Platte (OS/2 und Windows NT).

Mac OS, der PC-Austausch verwendet, versorgt seine verschiedenen Daten, Dateiattribute und lange Dateinamen in einer verborgenen Datei genannt"", und Quellengabeln (ein allgemeiner Mac OS ANZEIGEN) in einem genannten Unterverzeichnis",", in jedem Verzeichnis, wo sie verwendet werden. Vom PC-Austausch 2.1 vorwärts versorgen sie den Mac OS lange Dateinamen als lange FETTE Standarddateinamen und wandeln FETTE Dateinamen um, die länger sind als 31 Charaktere zu einzigartigen Dateinamen-Buchstaben 31, die dann sichtbar zu Anwendungen von Macintosh gemacht werden können. Vermutlich hat Sterntreck dieselben Mechanismen auf FAT12 und FAT16 Volumina 1992 verwendet.

Mac OS X versorgt Quellengabeln und metadata (Dateiattribute, andere ANZEIGEN) in einer verborgenen Datei mit einem Namen, der vom Eigentümerdateinamen gebaut ist, der mit" vorbefestigt ist", und Finder versorgt eine Mappe und Datei metadata in einer verborgenen genannten Datei "".

UMSDOS Erlaubnis und Dateinamen

Früher Linux Vertrieb hat auch ein Format bekannt als UMSDOS, eine FETTE Variante mit Dateiattributen von Unix (wie langer Dateiname und Zugriffserlaubnis) versorgt in einer getrennten genannten Datei "" unterstützt. UMSDOS ist in den Nichtgebrauch gefallen, nachdem VFAT veröffentlicht wurde und es standardmäßig in Kernen von Linux von der Version 2.5.7 vorwärts nicht ermöglicht wird.

Ableitungen

FATX

FATX ist eine Familie von Dateisystemen, die für die Xbox Videospiel-Konsole-Festplatte-Laufwerke des Microsofts und Speicherkarten entworfen sind, eingeführt 2001.

Während

man denselben grundlegenden Designideen wie FAT16 und FAT32, der FATX16 und FATX32 ähnelt, werden Strukturen auf der Platte vereinfacht, aber mit normalem FAT16 und FAT32 Dateisystemen im Wesentlichen unvereinbar, es unmöglich für normale FETTE Dateisystemfahrer machend, solche Volumina zu besteigen.

Der nichturladefähige Superblock-Sektor ist 4 in der Größe und hält eine 18 Bytes große BPB ähnliche Struktur völlig verschieden von normalem BPBs. Trauben sind normalerweise 16 in der Größe, und es gibt nur eine Kopie des FETTES auf Xbox. Verzeichniseinträge sind 64 Bytes in der Größe statt der normalen 32 Bytes. Dateien können Dateinamen bis zu 42 Charaktere lange mit der OEM-Codierung haben und bis zu 4 minus 1 Byte in der Größe sein. Die Zeitstempel auf der Platte halten Entwicklung, Modifizierung und Zugriffsdaten und Zeiten, aber unterscheiden sich von FETT: In FETT ist das Zeitalter 1980; in FATX ist das Zeitalter 2000. Auf Xbox 360 ist das Zeitalter 1980.

exFAT

exFAT ist ein unvereinbares Dateisystem, das mit Windows Eingebetteter CE 6.0 im November 2006 eingeführt wurde. Es basiert lose auf der Dateiaufteiler-Architektur, aber Eigentums- und geschützt durch Patente.

Der MBR Teilungstyp ist (dasselbe, wie verwendet, für IFS, HPFS, NTFS, usw.). exFAT ist für den Gebrauch auf Blitz-Laufwerken beabsichtigt (wie SDXC und Speicherstock XC), wo FAT32 sonst verwendet wird.

Es bietet mehrere Vorteile über FAT32 einschließlich des Brechens der 4 Dateigröße-Grenze von FAT32 an (nur ohne das FETT + Erweiterung, die Dateien erlaubt, die größer sind als 4 auch auf FAT32 Volumina), für Dateien raumeffizienter seiend, die kleiner sind als 64 auf großen Volumina und, im Vergleich zu Leichtgewichtsdurchführungen von FAT32 in DOS und einigen eingebetteten Systemen, kann es sich bieten schneller sucht, wenn mehr als einige tausend Dateien in einem einzelnen Unterverzeichnis versorgt werden, wohingegen FAT32 normalerweise schneller ist als exFAT für größere Dateien, wie verwendet, auf Digitalkameras, Kameras und Mediaspielern, oder wenn Blitz-Karten hauptsächlich zu archivalischen Zwecken verwendet werden.

Speichergeräte formatiert als exFAT können Daten mit der Ausrüstung nicht austauschen, die nicht das Format unterstützt. Viel Ausrüstung unterstützt exFAT nicht, der Erwerb einer Lizenz von Microsoft verlangt; das schließt Kosten ein, und ist auch gegen die Politik der offenen Quelle Betriebssysteme.

Technisches Design

Lay-Out

Ein FETTES Dateisystem wird aus vier verschiedenen Abteilungen zusammengesetzt:

• Die Vorbestellten Sektoren, die am wirklichen Anfang gelegen sind.

: Der erste vorbestellte Sektor (Sektor 0) ist der Stiefelsektor (auch bekannt als Volume Boot Record (VBR)). Es schließt ein Gebiet ein hat den BIOS Parameter-Block (mit etwas grundlegender Dateisysteminformation, insbesondere sein Typ und Zeigestöcke zur Position der anderen Abteilungen) genannt und enthält gewöhnlich den Stiefellader-Code des Betriebssystems.

: Die wichtige Information vom Stiefelsektor ist durch einen Betriebssystemaufbau genannt Drive Parameter Block (DPB) in DOS und OS/2 zugänglich.

: Die Gesamtzählung von vorbestellten Sektoren wird durch ein Feld innerhalb des Stiefelsektors angezeigt.

: Für FAT32 Dateisysteme schließen die vorbestellten Sektoren einen Dateisysteminformationssektor am Sektor 1 und einem Aushilfsstiefelsektor am Sektor 6 ein.

• Das FETTE Gebiet.

: Das enthält normalerweise zwei Kopien (kann sich ändern) des Dateiaufteilers wegen der Überfülle-Überprüfung, obwohl selten verwendet, sogar durch Plattenreparatur-Dienstprogramme.

: Das sind Karten des Datengebiets, anzeigend, welche Trauben durch Dateien und Verzeichnisse verwendet werden. In FAT12 und FAT16 folgen sie sofort den vorbestellten Sektoren.

: Normalerweise werden die Extrakopien in der dichten Synchronisation darauf behalten schreibt, und darauf liest sie werden nur verwendet, wenn Fehler im ersten FETT vorkommen. In FAT32 ist es möglich, vom Verzug-Verhalten umzuschalten und ein einzelnes FETT aus den verfügbaren zu Diagnose-Zwecken zu verwendenden auszuwählen.

• Das Wurzelverzeichnisgebiet.

: Das ist ein Verzeichnistisch, der Information über die Dateien und im Wurzelverzeichnis gelegenen Verzeichnisse versorgt. Es wird nur mit FAT12 und FAT16 verwendet, und erlegt dem Wurzelverzeichnis eine feste maximale Größe auf, die bei der Entwicklung dieses Volumens vorzugeteilt wird. FAT32 versorgt das Wurzelverzeichnis im Datengebiet, zusammen mit Dateien und anderen Verzeichnissen, ihm erlaubend, ohne solch eine Einschränkung zu wachsen. So, für FAT32, fängt das Datengebiet hier an.

• Das Datengebiet.

: Das ist, wo die wirkliche Datei und Verzeichnisdaten versorgt werden und den grössten Teil der Teilung aufnehmen. Traditionell werden die unbenutzten Teile des Datengebiets mit einem Füller-Wert während des Formats auf IBM vereinbare Maschinen initialisiert, sondern auch auf der Atari Mappe verwendet. 8-zöllige Floppy Discs des BEDIENUNGSFELDES/M sind normalerweise vorformatiert mit einem Wert dessen gekommen; über die Digitalforschung wurde dieser Wert auch auf formatierten Floppy Discs von Atari ST verwendet. Einige moderne formatters wischen Festplatten mit einem Wert dessen, wohingegen ein Wert dessen auf Blitz-Platten verwendet wird, um Tragen zu reduzieren. Der letzte Wert wird normalerweise auch auf ROM-Platten verwendet. (Einige sind vorwärts gegangen formatierende Werkzeuge erlauben, das Format-Füller-Byte zu konfigurieren.)

: Die Größe von Dateien und Unterverzeichnissen kann willkürlich vergrößert werden (als lange, weil es freie Trauben gibt) durch das einfache Hinzufügen von mehr Verbindungen zur Kette der Datei im FETT. Bemerken Sie jedoch, dass Dateien in Einheiten von Trauben so zugeteilt werden, wenn eine Datei in einer Traube wohnt, werden vergeudet.

: FAT32 fängt normalerweise den Wurzelverzeichnistisch in der Traube Nummer 2 an: die erste Traube des Datengebiets.

FETTER Gebrauch formatiert wenig-endian für alle Einträge im Kopfball (abgesehen von, wo ausführlich erwähnt, für einige Einträge auf Atari ST-Stiefelsektoren) und das FETT (E). Es ist möglich, FETTERE Sektoren zuzuteilen, als notwendig für die Zahl von Trauben. Das Ende des letzten FETTEN Sektors kann unbenutzt sein, wenn es keine entsprechenden Trauben gibt. Die Gesamtzahl von Sektoren (wie bemerkt, in der Stiefelaufzeichnung) kann größer sein als die Zahl von Sektoren, die durch Daten (Trauben × Sektoren pro Traube), FETTE (Zahl von FETTEN × Sektoren pro FETT) und verborgene Sektoren einschließlich des Stiefelsektors verwendet sind: Das würde auf unbenutzte Sektoren am Ende des Volumens hinauslaufen. Wenn eine Teilung mehr Sektoren enthält als die Gesamtzahl von durch das Dateisystem besetzten Sektoren, würde es auch auf unbenutzte Sektoren am Ende des Volumens hinauslaufen.

Stiefelsektor

Auf nichtverteilten Geräten, z.B, Disketten, ist der Stiefelsektor (VBR) der erste Sektor. Für verteilte Geräte wie Festplatten ist der erste Sektor die Master-Stiefelaufzeichnung das Definieren von Teilungen, während der erste Sektor von mit einem FETTEN Dateisystem formatierten Teilungen wieder der Stiefelsektor ist.

Die allgemeine Struktur der ersten 11 Bytes, die durch FETTESTE Versionen für IBM vereinbare X86-Maschinen seit DOS 2.0 verwendet sind, ist:

Fett-formatierte Atari ST-Floppy Discs haben ein sehr ähnliches Stiefelsektor-Lay-Out:

FAT12-formatierte MSX-DOS-Volumina haben ein sehr ähnliches Stiefelsektor-Lay-Out:

BIOS Parameter-Block

Die allgemeine Struktur der ersten 25 Bytes von BIOS Parameter Block (BPB), der durch FETTE Versionen seit DOS 2.0 verwendet ist, ist (Bytes am Sektor-Ausgleich dazu werden seit DOS 2.0 versorgt, aber nicht immer verwendet vor DOS 3.2 werden Werte an dazu seit DOS 3.0 verwendet):

DOS 3.0 BPB:

DOS 3.2 BPB:

DOS 3.31 BPB:

Eine einfache Formel übersetzt eine gegebene Traube-Zahl zu einer logischen Sektor-Zahl:

1. Bestimmen Sie (einmal), wo die vorbestellte Sektor-Zählung am Ausgleich, der FETTEN Zahl am Ausgleich, den Sektoren pro FETT am Ausgleich (FAT12/FAT16) oder (FAT32), den Wurzelverzeichniseinträgen am Ausgleich, der Sektor-Größe am Ausgleich versorgt wird, und zu einer ganzen Zahl zusammentreibt.
2. Bestimmen Sie, wo die Sektoren pro Traube am Ausgleich versorgt werden.

Eine Übersetzung von CHS dazu ist auch einfach: wo die Sektoren pro Spur am Ausgleich und der Zahl von Seiten am Ausgleich versorgt werden. Spur-Zahl, Hauptzahl und Sektor-Zahl entsprechen Zylinderkopf-Sektor: Die Formel gibt den bekannten CHS der LBA Übersetzung.

Erweiterter BIOS Parameter-Block

Weitere Struktur, die durch FAT12 und FAT16 seit OS/2 1.0 und DOS 4.0, auch bekannt als Extended BIOS Parameter Block (EBPB) verwendet ist (sind Bytes unter dem Sektor-Ausgleich dasselbe bezüglich DOS 3.31 BPB):

FAT32 verlängerter BIOS Parameter-Block

Hauptsächlich fügt FAT32 28 Bytes in den EBPB ein, der von den restlichen 26 Bytes, wie gezeigt, oben für FAT12 und FAT16 gefolgt ist:

Ausnahmen

Die Durchführung von FETT, das im MS-DOS für den Aprikose-PC verwendet ist, hatte ein verschiedenes Stiefelsektor-Lay-Out, um Nichtibm dieses Computers vereinbarer BIOS unterzubringen. Die Sprung-Instruktion und der OEM-Name wurden weggelassen, und die MS-DOS-Dateisystemrahmen (Ausgleiche - im Standardsektor) wurden am Ausgleich gelegen. Spätere Versionen des Aprikose-MS-DOS haben die Fähigkeit gewonnen, Platten mit dem Standardstiefelsektor zusätzlich zu denjenigen mit der Aprikose ein zu lesen und zu schreiben.

DOS Plus auf dem BBC-Master 512 hat herkömmliche Stiefelsektoren überhaupt nicht verwendet. Datenplatten haben den Stiefelsektor weggelassen und haben mit einer einzelnen Kopie des FETTES begonnen (das erste Byte des FETTES wurde verwendet, um Plattenkapazität zu bestimmen), während Stiefelplatten mit einem ADFS Miniaturdateisystem begonnen haben, das den Stiefellader enthält, der von einem einzelnen FETT gefolgt ist. Es konnte auch auf Standard-PC-Platten zugreifen, die zu oder wieder mit dem ersten Byte des FETTES formatiert sind, um die Kapazität zu bestimmen.

FS Informationssektor

Der FS "Informationssektor" wurde in FAT32 eingeführt, um Zugriffszeiten von bestimmten Operationen zu beschleunigen (insbesondere den Betrag des freien Raums bekommend). Es wird an einer logischen Sektor-Zahl gelegen, die im FAT32 EBPB Stiefelaufzeichnung an der Position (gewöhnlich logischer Sektor 1, sofort nach der Stiefelaufzeichnung selbst) angegeben ist.

Die Daten des Sektors können überholt sein und den aktuellen Mediainhalt nicht widerspiegeln, weil nicht alle Betriebssysteme aktualisieren oder diesen Sektor verwenden, und selbst wenn sie tun, der Inhalt ist nicht gültig, als das Medium vertrieben worden ist, ohne das Volumen oder nach einem Macht-Misserfolg richtig unzubesteigen. Deshalb sollten Betriebssysteme zuerst einen fakultativen Stilllegungsstatus eines Volumens bitflags das Wohnen im FETTEN Zugang der Traube 1 oder der FAT32 EBPB am Ausgleich untersuchen und die im FS Informationssektor versorgten Daten ignorieren, wenn diese bitflags anzeigen, dass das Volumen vorher nicht richtig unmontiert war. Das verursacht keine Probleme außer einer möglichen Geschwindigkeitsstrafe für die erste freie Raumabfrage oder Datentraube-Zuteilung; sieh Zersplitterung.

Wenn dieser Sektor auf einem FAT32 Volumen da ist, ist die minimale erlaubte logische Sektor-Größe 512 Bytes, wohingegen sonst es 128 Bytes sein würden. Einige FAT32 Durchführungen unterstützen eine geringe Schwankung der Spezifizierung des Microsofts durch das Bilden des FS Informationssektors fakultativ durch das Spezifizieren eines Werts von 0 im Zugang am Ausgleich.

Dateiaufteiler

Eine Teilung wird in identisch große Trauben, kleine Blöcke des aneinander grenzenden Raums zerteilt. Traube-Größen ändern sich abhängig vom Typ des FETTEN Dateisystems, das wird verwendet und der Größe der Teilung normalerweise liegen Traube-Größen irgendwo zwischen und.

Jede Datei kann ein oder mehr von diesen Trauben abhängig von seiner Größe besetzen; so wird eine Datei durch eine Kette dieser Trauben (gekennzeichnet als eine einzeln verbundene Liste) vertreten. Jedoch werden diese Trauben neben einander auf der Oberfläche der Platte nicht notwendigerweise versorgt, aber werden häufig stattdessen überall im Datengebiet gebrochen.

File Allocation Table (FAT) ist eine Liste von Einträgen, die zu jeder Traube auf der Teilung kartografisch darstellen. Jeder Zugang registriert eines von fünf Dingen:

• die Traube-Zahl der folgenden Traube in einer Kette
• ein spezielles Ende der Traube-Kette (EOC) Zugang, der das Ende einer Kette anzeigt
• ein spezieller Zugang, um eine schlechte Traube zu kennzeichnen
• eine Null, um zu bemerken, dass die Traube unbenutzter ist

Jede Version des FETTEN Dateisystems verwendet eine verschiedene Größe für FETTE Einträge. Kleinere Zahlen laufen auf ein kleineres FETT hinaus, aber vergeuden Raum in großen Teilungen, indem sie in großen Trauben zuteilen muss. Das FAT12 Dateisystem verwendet 12-Bit-ProFettzugang, so messen zwei Einträge 3 Bytes ab. Es ist durchweg wenig-endian: Wenn jene drei Bytes als eine wenig-endian 24 Bit Zahl betrachtet werden, vertreten die 12 am wenigsten bedeutenden Bit den ersten Zugang (Traube 0) und die 12 bedeutendsten Bit das zweite (Traube 1).

Die ersten zwei Einträge in einem FETTEN Laden spezielle Werte:

Der erste Zugang (Traube 0 im FETT) hält den Mediadeskriptor (erlaubt Werte - mit - vorbestellt), der auch in den BPB des Stiefelsektors kopiert, seit DOS 2.0 ausgeglichen wird. Die restlichen 4 Bit (wenn FAT12), 8 Bit (wenn FAT16) oder 20 Bit (wenn FAT32) dieses Zugangs sind immer 1. Für Mediadeskriptoren außer (und) ist es möglich, das richtige Nagen und die Byte-Ordnung zu bestimmen (um zu sein), verwendet vom Dateisystemfahrer jedoch das FETTE Dateisystem verwendet offiziell wenig-endian Darstellung nur, und es gibt keine bekannten Durchführungen von Varianten mit großen-endian Werten stattdessen.

Der zweite Zugang (Traube 1 im FETT) versorgt nominell das Ende des Traube-Kettenanschreibers, wie verwendet, durch den formater, aber hält normalerweise immer//, d. h. mit Ausnahme von Bit 31-28 auf FAT32 Volumina diese Bit werden normalerweise immer gesetzt. Betriebssysteme eines Microsofts setzen jedoch diese Bit, wenn das Volumen nicht das Volumen ist, das das Laufen Betriebssystem (d. h. Gebrauch statt hier) hält. (In Verbindung mit alternativen Anschreibern des Endes der Kette können die niedrigsten Bit 2-0 Null für den niedrigsten erlaubten Anschreiber des Endes der Kette / / werden; Bit 3 sollte ebenso gegeben vorbestellt werden, dass Trauben / / und höher offiziell vorbestellt werden.)

Seit DOS 7.1 die zwei die meisten - können bedeutende Bit des Traube-Zugangs zwei fakultative bitflags das Darstellen des aktuellen Volumen-Status auf FAT16 und FAT32, aber nicht auf FAT12 Volumina halten. Diese bitflags werden durch alle Betriebssysteme nicht unterstützt, aber Betriebssysteme, die diese Eigenschaft unterstützen, würden diese Bit auf der Stilllegung setzen und das bedeutendste Bit auf dem Anlauf klären:

Wenn Bit 15 (FAT16) beziehungsweise 27 (FAT32) gebissen hat, wird nicht gesetzt, wenn man das Volumen besteigt, das Volumen war vor der Stilllegung oder Ausweisung nicht richtig unmontiert und ist so in einem unbekannten und vielleicht "schmutzigem" Staat. Auf FAT32 Volumina kann der FS Informationssektor überholte Daten halten und sollte so nicht verwendet werden. Das Betriebssystem würde dann normalerweise CHKDSK auf dem folgenden Anlauf (aber nicht auf der Einfügung von absetzbaren Medien) führen, um vielleicht die Integrität des Volumens zu sichern und wieder herzustellen.

Wenn Bit 14 (FAT16) beziehungsweise 26 (FAT32) gebissen hat, wird geklärt, das Betriebssystem ist auf Platteneingabe/Ausgabe-Fehler gestoßen, als es verwendet, eine mögliche Anzeige für schlechte Sektoren letzt war. Dieser Erweiterung bewusste Betriebssysteme werden das als eine Empfehlung interpretieren, ein Oberflächenansehen (SCANDISK) auf dem folgenden Stiefel auszuführen. (Ein ähnlicher Satz von bitflags besteht im FAT12/FAT16 EBPB am Ausgleich oder dem FAT32 EBPB am Ausgleich. Während die Traube auf 1 Zugang kann von Dateisystemfahrern zugegriffen werden, sobald sie das Volumen, der EBPB Zugang bestiegen haben, verfügbar ist, selbst wenn das Volumen nicht bestiegen und so leichter wird, durch Plattenblock-Gerät-Treiber oder Verteilen-Werkzeuge zu verwenden.)

Wenn die Zahl von FETTEN im BPB auf 2 nicht gesetzt wird, kann der zweite Traube-Zugang im ersten FETT (Traube 1) auch den Status eines TFAT Volumens für TFAT-bewusste Betriebssysteme widerspiegeln. Wenn die Traube 1 Zugang in diesem FETT hält den Wert 0, das anzeigen kann, dass das zweite FETT den letzten bekannten gültigen Transaktionsstaat vertritt und über das erste FETT kopiert werden sollte, wohingegen das erste FETT über das zweite FETT kopiert werden sollte, wenn alle Bit gesetzt werden.

Weil diese ersten zwei FETTEN Einträge spezielle Werte versorgen, gibt es keine Datentraube 0 oder 1. Die erste Datentraube (nach dem Wurzelverzeichnis wenn FAT12/FAT16) ist Traube 2.

FETTE Zugang-Werte:

Trotz seines Namens FAT32 verwendet nur 28 Bit der 32 möglichen Bit. Die oberen 4 Bit sind gewöhnlich Null, aber werden vorbestellt und sollten unberührt verlassen werden. Ein Standard conformant FAT32 Dateisystemtreiber oder Wartungswerkzeug muss sich auf die oberen 4 Bit nicht verlassen, um Null zu sein, und es muss sie vor dem Auswerten der Traube-Zahl ausziehen, um mit möglichen zukünftigen Vergrößerungen fertig zu werden, wo diese Bit zu anderen Zwecken verwendet werden können. Sie müssen vom Dateisystemfahrer nicht geklärt werden, wenn man neue Trauben zuteilt, aber sollten während eines Wiederformats geklärt werden.

Verzeichnistisch

Ein Verzeichnistisch ist ein spezieller Typ der Datei, die ein Verzeichnis (auch bekannt als eine Mappe) vertritt. Jede Datei oder innerhalb seiner versorgtes Verzeichnis werden durch einen 32-Byte-Zugang im Tisch vertreten. Jeder Zugang registriert den Namen, die Erweiterung, Attribute (Archiv, Verzeichnis, verborgen, read-only-, System und Volumen), das Datum und Zeit der letzten Modifizierung, die Adresse der ersten Traube der Daten der Datei/Verzeichnisses und schließlich der Größe der Datei/Verzeichnisses.

Beiseite vom Wurzelverzeichnistisch in FAT12 und FAT16 Dateisystemen, der die spezielle Wurzelverzeichnisgebiet-Position besetzt, werden alle Verzeichnistische im Datengebiet versorgt. Die wirkliche Zahl von Einträgen in einem im Datengebiet versorgten Verzeichnis kann durch das Hinzufügen einer anderen Traube zur Kette im FETT wachsen.

Das FETTE Dateisystem selbst setzt keine Grenzen auf der Tiefe eines Unterverzeichnis-Baums für fest, so lange es freie Trauben gibt, die verfügbar sind, um die Unterverzeichnisse jedoch zuzuteilen, beschränkt die Aktuelle Verzeichnisstruktur unter MS-DOS/PC DOS den absoluten Pfad eines Verzeichnisses zu 66 Charakteren (einschließlich des Laufwerk-Briefs, aber des Nullbegrenzungszeichens ausschließend), dadurch die maximale unterstützte Tiefe von Unterverzeichnissen zu 32 beschränkend, was auch immer früher vorkommt. Gleichzeitiger DOS, Mehrbenutzer, den DOS und DR DOS 3.31 zu 6.0 (bis zum Umfassen der 1992-11 Aktualisierungen) absolute Pfade zu Arbeitsverzeichnissen innerlich nicht versorgen und deshalb dieser Beschränkung nicht zeigen. Dasselbe gilt für Atari GEMDOS, aber die Atari Arbeitsfläche unterstützt mehr als 8 Unterverzeichnis-Niveaus nicht. Die meisten dieser Erweiterung bewussten Anwendungen unterstützen Pfade bis zu mindestens 127 Bytes. FlexOS, 4680 OS und 4690 OS unterstützen eine Länge von bis zu 127 Bytes ebenso, Tiefen unten 60 Niveaus erlaubend. PalmDOS, DR DOS 6.0 (seit BDOS 7.1) und höher, Novell DOS und Sport von OpenDOS ein mit dem MS DOS VEREINBARER CDS und haben deshalb dieselben Länge-Grenzen wie MS-DOS/PC DOS.

Bemerken Sie, dass vor jedem Zugang dort "unechte Einträge" sein kann, um einen langen Dateinamen (LFN) zu unterstützen; sieh weiter unten.

Gesetzliche Charaktere für DOS kurze Dateinamen schließen den folgenden ein:

• Großbuchstaben-Briefe -
• Zahlen -
• Raum (obwohl, wie man betrachtet, nachfolgende Leerzeichen entweder im Grundnamen oder in der Erweiterung auspolstern und nicht ein Teil des Dateinamens, auch Dateinamen mit dem Raum in ihnen, konnte auf der DOS-Befehl-Linie vor Windows 95 wegen des Mangels an einem passenden flüchtenden System nicht leicht verwendet werden). Eine andere Ausnahme ist die inneren Befehle / und / unter DR-DOS, die einzelne Argumente akzeptieren und deshalb Räumen erlauben, eingegangen zu werden.
• Werte 128-255

Das schließt die folgenden ASCII Charaktere aus:

• Ihnen wird in langen Dateinamen nur erlaubt.
• Briefe der unteren Umschaltung - Versorgt als-. Erlaubt in langen Dateinamen.
• Kontrollcharaktere 0-31
• Schätzen Sie 127 (DEL)

Den folgenden zusätzlichen Charakteren wird auf dem GEMDOS von Atari erlaubt, aber sollte für die Vereinbarkeit mit MS-DOS/PC DOS vermieden werden:

Der Strichpunkt sollte in Dateinamen unter DR DOS 3.31 und höher, PalmDOS, Novell DOS, OpenDOS, Gleichzeitiger DOS, Mehrbenutzer DOS, Systemverwalter und ECHT/32 vermieden werden, weil es die Syntax kollidieren kann, um Datei und Verzeichniskennwörter anzugeben: "". Das Betriebssystem wird einen (und auch zwei - seit DR-DOS 7.02) Strichpunkte und während Kennwörter von den Dateinamen vor der Speicherung von ihnen auf der Platte ausziehen. (Der Befehl-Verarbeiter 4DOS verwendet Strichpunkte dafür schließen Listen ein, und verlangt, dass der für das Kennwort zu verdoppelnde Strichpunkt Dateien mit irgendwelchen Befehlen geschützt hat, die Wildcards unterstützen.)

-Buchstaben wird für filelists von vielen DR-DOS, PalmDOS, Novell DOS, OpenDOS und Mehrbenutzer-DOS, Systemverwalter und ECHTE/32 Befehle sowie durch 4DOS verwendet und kann deshalb manchmal schwierig sein, in Dateinamen zu verwenden.

Unter Mehrbenutzer-DOS und ECHT/32 ist das Ausrufungszeichen (!) nicht ein gültiger Dateinamencharakter, da es verwendet wird, um vielfache Befehle in einer einzelnen Befehl-Linie zu trennen.

Unter IBM 4680 OS und 4690 OS wird den folgenden Charakteren in Dateinamen nicht erlaubt:

Zusätzlich wird den folgenden speziellen Charakteren im ersten, vierten, fünften und acht Charakter eines Dateinamens nicht erlaubt, weil sie den Gastgeber-Befehl-Verarbeiter (HCP) kollidieren und Folge-Tisch eingeben, bauen Dateinamen:

Die DOS-Dateinamen sind in der aktuellen OEM-Codierung: Das kann überraschende Effekten haben, wenn Charaktere, die auf eine Weise für eine gegebene Codeseite behandelt sind, verschieden für eine andere Codeseite (DOS-Befehl CHCP) in Bezug auf untere Umschaltung und Großbuchstaben, das Sortieren oder die Gültigkeit als Dateiname-Charakter interpretiert werden.

Verzeichniszugang

Bevor Microsoft Unterstützung für lange Dateinamen und Marken der Entwicklung/Zugriffszeit hinzugefügt hat, wurden Bytes - des Verzeichniszugangs durch andere Betriebssysteme verwendet, um zusätzlichen metadata zu versorgen, am meisten namentlich die Betriebssysteme der Digitalforschungsfamilie haben Dateikennwörter, Zugriffsrechte, Eigentümerpersonalausweise und Dateiauswischen-Daten dort versorgt. Während die neueren Erweiterungen des Microsofts mit diesen Erweiterungen standardmäßig nicht völlig vereinbar sind, können die meisten von ihnen in FETTEN Drittdurchführungen (mindestens auf FAT12 und FAT16 Volumina) koexistieren.

Verzeichniseinträge, sowohl im Wurzelverzeichnisgebiet als auch in Unterverzeichnissen, sind vom folgenden Format (sieh auch 8.3 Dateinamen):

Versionen von DOS vor 5.0 Anfang, Verzeichnistische von der Spitze des Verzeichnistisches zum Boden scannend. Um Chancen für das erfolgreiche Dateiunauswischen, DOS 5.0 zu vergrößern und sich höher an die Position des letzten schriftlichen Verzeichniszugangs erinnern und das als ein Startpunkt für das Verzeichnistabellenansehen verwenden wird.

| -

| Stil = "text-align:Right;" | 0x08

| Stil = "text-align:Right;" | 3

| Kurze Dateierweiterung (ausgepolstert mit Räumen)

| -

| Stil = "text-align:Right;" | 0x0B

| Stil = "text-align:Right;" | 1

| Datei schreibt zu

Unter DR DOS 6.0 und höher, einschließlich PalmDOS, Novell DOS und OpenDOS, wird das Volumen-Attribut für während gesetzt löschen Dateien und Verzeichnisse unter DELWATCH.

Eine Attribut-Kombination dessen wird verwendet, um einen VFAT langer Dateiname-Zugang seit dem MS-DOS 7.0 zu benennen. Ältere Versionen von DOS können das mit einem Verzeichnisvolumen-Etikett verwechseln, weil sie den ersten Zugang mit dem Volumen-Attribut-Satz als Volumen-Etikett nehmen. Dieses Problem kann vermieden werden, wenn ein Verzeichnisvolumen-Etikett als ein Teil des Format-Prozesses beachtet wird; aus diesem Grund schreiben einige Plattenwerkzeuge ausführlich Modepuppe "" Verzeichnisvolumen-Etiketten, wenn der Benutzer kein Volumen-Etikett angibt. Da Volumen-Etiketten normalerweise den Systemattribut-Satz zur gleichen Zeit nicht haben, ist es möglich, zwischen Volumen-Etiketten und VFAT LFN Einträge zu unterscheiden. Die Attribut-Kombination konnte gelegentlich auch vorkommen, weil ein Teil eines gültigen während Datei unter DELWATCH jedoch auf FAT12 löscht und FAT16 Volumina, VFAT LFN Einträge immer den Traube-Wert am Satz dazu haben und der Länge-Zugang daran nie ist, wohingegen der Zugang daran immer Nichtnull für während ist, löschen Dateien unter DELWATCH (mit der möglichen Ausnahme von Nulllänge-Dateien oder gelöschten Dateien im Anschluss an den FAT16 + Vorschlag, der durch an angezeigt ist). Diese Kontrolle arbeitet an FAT32 Volumina nicht.

| -

| Stil = "text-align:Right;" | 0x0C

| Stil = "text-align:Right;" | 1|

• CP/M-86 und schreibt DOS Plus der Lager-Benutzer F1 '-F4' hier zu. (DOS Plus 1.2 mit BDOS 4.1 Unterstützungskennwörter nur auf Medien des BEDIENUNGSFELDES/M, nicht auf FAT12 oder FAT16 Medien. Während DOS Plus 2.1 unterstützte logische sectored FETTE mit einem Teilungstyp, FAT16B und FAT32 Volumina durch diese Operationssysteme nicht unterstützt wurde. Selbst wenn eine Teilung zu FAT16B umgewandelt worden sein würde, würde es noch immer nicht größer sein als 32 Mb. Deshalb ist dieser Gebrauch nicht conflictive mit FAT32. IFS, FAT16 + oder FAT32 +, weil sie auf demselben Typ des Volumens nie vorkommen können.):
• MSX-DOS 2: Für eine gelöschte Datei, den ursprünglichen ersten Charakter des Dateinamens. Für dieselbe Eigenschaft in verschiedenen anderen Betriebssystemen, sieh Ausgleich, wenn ermöglicht, in MSX-Stiefelsektoren am Sektor-Ausgleich. MSX-DOS hat FAT12 Volumina nur unterstützt, aber Dritterweiterungen für FAT16 Volumina bestehen. Deshalb ist dieser Gebrauch nicht conflictive mit FAT32. IFS und FAT32 + unten. Es kollidiert den Gebrauch für Benutzerattribute unter CP/M-86 und DOS Plus ebenso nicht, da sie für gelöschte Dateien nicht mehr wichtig sind.
• Windows NT und spätere Versionen verwenden Bit 3 und 4, um Fall-Information (sieh unten) zu verschlüsseln; sonst 0.
• DR-DOS 7.0x hat Bit außer 3 und 4 zu inneren Zwecken seit 1997 vorbestellt. Der Wert sollte auf 0 durch das Formatieren von Werkzeugen gesetzt werden und muss durch Plattenwerkzeuge nicht geändert werden.
• Auf FAT32 Volumina unter OS/2 und eComStation der Dritt-FAT32. IFS Fahrer verwertet diesen Zugang als ein Zeichen-Byte, um die Anwesenheit von" "Extradateien anzuzeigen, die erweiterte Attribute mit dem Parameter halten. Version 0.70 zu 0.96 hat die magischen Werte (kein EAs), (normaler EAs) und (kritischer EAs), wohingegen Version 0.97 und höher seit 2003-09 Gebrauch, (normaler EAs) und (kritischer EAs) als bitflags für die Vereinbarkeit mit Windows NT verwendet.
• Bit außer 3 und 4 werden durch FETT +, ein Vorschlag verwertet, wie man Dateien versorgt, die größer sind als 4 GB auf FAT32 (und FAT16B) Volumina zurzeit die in einigen Versionen von EDR-DOS und FreeDOS durchgeführt sind. Der Wert sollte auf 0 durch das Formatieren von Werkzeugen gesetzt werden und muss durch Plattenwerkzeuge nicht geändert werden. Wenn einige dieser Bit gesetzt werden, sollten sich nichtermöglichte Durchführungen weigern, die Datei zu öffnen. Um Probleme mit nichtbewussten Betriebssystemen zu vermeiden, konnten Teilungen, die Dateien enthalten, die größer sind als 4 GB, Sonderteilungspersonalausweise verwenden, um die Teilung vor diesen Betriebssystemen zu verbergen. Unter DR-DOS können Teilungspersonalausweise von gesicherten Teilungstypen für diesen Zweck verwertet werden. Dateien, die größer sind als 4 GB, sollten das Verborgene, den Read-only-haben, und Systemattribut-Satz, um sie vor normalen Verzeichnissuchen auf nichtbewussten Betriebssystemen zu verbergen, die dem Kennwort ähnlich sind, hat Dateien unter DR-DOS geschützt. Während FETT + sich Durchführungen auf diese Attribute nicht verlassen, die setzen werden, für FETT + große Dateien können sie diese Attribute in Dateisuchen ignorieren, und wenn sie große Dateien für die Modifizierung öffnen, und stattdessen das Systemattribut behandeln, weil eine Alternative verbunden Read-only+Hidden in diesem Drehbuch zuschreibt.

FAT32. IFS ist kritisch conflictive mit FAT32 + Revision 2.

| -

| Stil = "text-align:Right;" | 0x0D

| Stil = "text-align:Right;" | 1|

• Der erste Charakter einer gelöschten Datei unter Novell DOS, OpenDOS und DR-DOS 7.02 und höher. Ein Wert von (229), wie gesetzt, durch DELPURGE, wird Unauswischen dadurch verbieten stellen WIEDER HER, ein Wert dessen wird herkömmliches Unauswischen erlauben, das den Benutzer um den fehlenden ersten Dateinamencharakter bittet. S/DOS 1 und PTS-DOS 6.51 und unterstützen höher auch diese Eigenschaft, wenn ermöglicht, mit in CONFIG.SYS. Für dieselbe Eigenschaft in MSX-DOS, sieh Ausgleich.
• Schaffen Sie Zeit, Feine Entschlossenheit: Die Einheiten von 10 Millisekunde, Werte von 0 bis 199 (seit DOS 7.0 mit VFAT).

Doppelter Gebrauch dafür schafft Zeitmillisekunde, und Dateirotforelle ist nicht conflictive, da die Entwicklungszeit für gelöschte Dateien nicht mehr wichtig ist.

| -

| Stil = "text-align:Right;" | 0x0E

| Stil = "text-align:Right;" | 2

|

• Unter DR DOS 3.31 und höher einschließlich PalmDOS, Novell DOS und OpenDOS sowie unter Gleichzeitigem DOS, Mehrbenutzer DOS, Systemverwalter, und ECHT/32 und vielleicht auch unter FlexOS, 4680 OS, 4690 OS zeigt jeder Nichtnullwert das Kennwort-Kuddelmuddel einer geschützten Datei, Verzeichnisses oder Volumen-Etiketts an. Das Kuddelmuddel wird von den ersten acht Charakteren eines Kennwortes berechnet. Wenn die auszuführende Dateioperation ein Kennwort laut der Zugriffsrechte bitmap versorgt am Ausgleich verlangt, versucht das System, das Kuddelmuddel gegen den Kuddelmuddel-Code zurzeit Satz globales Kennwort (durch) zu vergleichen, oder, wenn das scheitert, sind Versuche, ein Strichpunkt-angehangenes Kennwort aus dem filespec herauszuziehen, zum Betriebssystem gegangen und überprüfen es gegen den Kuddelmuddel-Code versorgt hier. Ein Satz-Kennwort wird bewahrt, selbst wenn eine Datei gelöscht und später wieder hergestellt wird.
• Schaffen Sie Zeit (seit DOS 7.0 mit VFAT). Die Stunde, Minute und zweit werden gemäß dem folgenden bitmap verschlüsselt:

:The-Sekunden werden nur zu einer 2 zweiten Entschlossenheit registriert. Die feinere Entschlossenheit für die Dateientwicklung wird am Ausgleich gefunden.

Wenn Bit 15-11> 23 oder Bit 10-5> 59 oder Bit 4-0> 29 hier, oder wenn Bit 12-0 am Ausgleich einen Zugang bitmap halten und das nicht ein FAT32 Volumen oder ein Volumen mit OS/2 Verlängerte Attribute ist, dann hält dieser Zugang wirklich ein Kennwort-Kuddelmuddel, sonst, wie man annehmen kann, ist es eine Dateientwicklungszeit.

| -

| Stil = "text-align:Right;" | 0x10

| Stil = "text-align:Right;" | 2|

• FlexOS, 4680 OS und 4690 OS versorgen eine Rekordgröße im Wort beim Zugang. Das wird für ihre speziellen datenbankähnlichen Dateitypen hauptsächlich verwendet zufällige Datei, direkte Datei, hat Datei und folgende Datei eingegeben. Wenn die Rekordgröße auf 0 (Verzug) oder 1 gesetzt wird, nehmen die Betriebssysteme eine Rekordkörnung von 1 Byte für die Datei an, für die es Rekordgrenzcheck-Ins von Lesen/Schreiben-Operationen nicht durchführen wird.
• Mit DELWATCH 2.00 und höher unter Novell DOS 7, OpenDOS 7.01 und DR-DOS 7.02 und höher, wird dieser Zugang verwendet, um den letzten modifizierten Zeitstempel für während zu versorgen, löschen Dateien und Verzeichnisse. Geklärt, wenn Datei wieder hergestellt oder gereinigt wird. Sieh Ausgleich für eine Format-Beschreibung.
• Schaffen Sie Datum (seit DOS 7.0 mit VFAT). Das Jahr, der Monat und der Tag werden gemäß dem folgenden bitmap verschlüsselt:

Der Gebrauch für das Entwicklungsdatum für vorhandene Dateien und letztes modifiziertes Mal für gelöschte Dateien ist nicht conflictive, weil sie zur gleichen Zeit nie verwendet werden. Aus demselben Grund ist der Gebrauch für die Rekordgröße von vorhandenen Dateien und letztes modifiziertes Mal von gelöschten Dateien nicht conflictive ebenso. Entwicklungsdaten und Rekordgrößen können zur gleichen Zeit jedoch nicht verwendet werden, beide werden nur auf der Dateientwicklung versorgt und nie später geändert, dadurch den Konflikt auf FlexOS, 4680 OS und 4690 OS Systeme beschränkend, die auf Dateien zugreifen, die unter Auslandsbetriebssystemen sowie potenzieller Anzeige oder Dateisortieren-Problemen auf Systemen geschaffen sind, die versuchen, eine Rekordgröße als Entwicklungszeit zu interpretieren. Um den Konflikt zu vermeiden, sollte die Lagerung von Entwicklungsdaten eine optionale Zusatzeinrichtung von Betriebssystemen sein, die es unterstützen.

| -

| Stil = "text-align:Right;" | 0x12

| Stil = "text-align:Right;" | 2|

• FlexOS, 4680 OS, 4690 OS, Mehrbenutzer DOS, Systemverwalter, ECHT/32 und DR DOS 6.0 und höher mit der Mehrbenutzersicherheit haben Gebrauch dieses Feld ermöglicht, um Eigentümerpersonalausweise zu versorgen. Ausgleich hält den Benutzerpersonalausweis, den Gruppenpersonalausweis eines Schöpfers einer Datei.

:In-Mehrbenutzerversionen, Systemzugang verlangt einen logon mit der Kontenbezeichnung und dem Kennwort, und das System teilt Gruppe und Benutzerpersonalausweise zu laufenden Anwendungen gemäß dem vorher aufgestellten und versorgten Genehmigungsinfo und Erbe-Regeln zu. Für 4680 OS und 4690 OS wird Gruppenpersonalausweis 1 für das System, den Gruppenpersonalausweis 2 für den Verkäufer, den Gruppenpersonalausweis 3 für die Verzug-Benutzergruppe vorbestellt. Mit Benutzern angefangene Hintergrundanwendungen haben einen Gruppenpersonalausweis 2 und Benutzerpersonalausweis 1, wohingegen Betriebssystemhintergrundaufgaben Gruppenpersonalausweise 1 oder 0 und Benutzerpersonalausweise 1 oder 0 haben. IBM 4680 BASIC und Anwendungen haben angefangen, weil primär oder sekundär immer Gruppenpersonalausweis 2 und Benutzerpersonalausweis 1 bekommen. Wenn Anwendungen Dateien schaffen, wird das System ihren Benutzerpersonalausweis und Gruppenpersonalausweis und die erforderliche Erlaubnis mit der Datei versorgen.

• Mit DELWATCH 2.00 und höher unter Novell DOS 7, OpenDOS 7.01 und DR-DOS 7.02 und höher, wird dieser Zugang verwendet, um die letzte modifizierte Datum-Marke für während zu versorgen, löschen Dateien und Verzeichnisse. Geklärt, wenn Datei wieder hergestellt oder gereinigt wird. Sieh Ausgleich für eine Format-Beschreibung.
• Letztes Zugriffsdatum (da DOS 7.0, wenn ACCDATE in CONFIG.SYS für den entsprechenden Laufwerk ermöglicht hat); sieh Ausgleich für eine Format-Beschreibung.

Der Gebrauch für die Eigentümerpersonalausweise von vorhandenen Dateien und letzter modifizierter Datum-Marke für gelöschte Dateien ist nicht conflictive, weil sie zur gleichen Zeit nie verwendet werden. Der Gebrauch der letzten modifizierten Datum-Marke für gelöschte Dateien und Zugriffsdatum ist auch nicht conflictive, da Zugriffsdaten für gelöschte Dateien jedoch nicht mehr wichtig sind, können Eigentümerpersonalausweise und Zugriffsdaten nicht zur gleichen Zeit verwendet werden.

| -

| Stil = "text-align:Right;" | 0x14

| Stil = "text-align:Right;" | 2|

• Zugriffsrechte bitmap für die Welt/Gruppe/Eigentümer lasen Schutz für geschützte Dateien des Kennwortes, Verzeichnisse (oder Volumen-Etiketten) unter DR DOS 3.31 und höher, einschließlich PalmDOS, Novell DOS und OpenDOS, und unter FlexOS, 4680 OS, 4690 OS, Gleichzeitigem DOS, Mehrbenutzer DOS, Systemverwalter, und ECHT/32/schrieben/durchführten/löschten.

Auf einem Einzelbenutzersystem versorgte:Typical-Werte sind (für alle Zugriffsrechte "RWED"), (für Zugriffsrechte "RW? -"), (für Zugriffsrechte "R-?-") und (für Dateien oder für Verzeichnisse für Zugriffsrechte "-? -"). Bit 1, 5, 9, 12-15 werden bewahrt, wenn man Zugriffsrechte ändern wird. Wenn Bit durchführen, werden auf Systemen außer FlexOS, 4680 OS oder 4690 OS gesetzt, sie werden ähnlich behandelt, um Bit zu lesen. (Einige Versionen des KENNWORTES erlauben, Kennwörter auf Volumen-Etiketten ebenso zu setzen.)

:Single-Benutzersysteme berechnen die einschränkendsten Rechte auf die drei Sätze (DR DOS bis zu 5.0 verwendete Bit 0-3 nur) und Kontrolle, wenn einige der gebetenen Dateizugriffstypen eine Erlaubnis verlangt, und wenn ein Dateikennwort versorgt wird. Wenn nicht, Dateizugang wird gewährt. Sonst wird das versorgte Kennwort gegen ein fakultatives globales Kennwort überprüft, das durch das Betriebssystem und ein fakultatives Dateikennwort zur Verfügung gestellt ist, zur Verfügung gestellt als ein Teil des Dateinamens, der durch einen Strichpunkt (nicht unter FlexOS, 4680 OS, 4690 OS) getrennt ist. Wenn keiner von ihnen zur Verfügung gestellt wird, wird die Bitte scheitern. Wenn einer von ihnen zusammenpasst, wird das System Zugang gewähren (innerhalb der Grenzen der normalen Dateiattribute, d. h. eine Read-Only-Datei kann dafür noch immer nicht geöffnet werden schreiben diesen Weg), fehlen Sie sonst der Bitte.

:Under FlexOS, 4680 OS und 4690 OS das System teilt Gruppe und Benutzerpersonalausweise zu Anwendungen, wenn gestartet, zu. Wenn sie um Dateizugang bitten, sind ihre Gruppe und Benutzerpersonalausweise im Vergleich zur Gruppe und den Benutzerpersonalausweisen der zu öffnenden Datei. Wenn beide Personalausweise zusammenpassen, wird die Anwendung als Dateieigentümer behandelt. Wenn nur die Gruppen-ID-Matchs, das Betriebssystem Gruppenzugang zur Anwendung gewähren wird, und wenn der Gruppenpersonalausweis ebenso nicht zusammenpasst, wird es Weltzugang gewähren. Wenn ein Gruppenpersonalausweis einer Anwendung und Benutzerpersonalausweis beide 0 sind, wird das Betriebssystem Sicherheitsüberprüfung umgehen. Sobald die Erlaubnis-Klasse bestimmt worden ist, wird das Betriebssystem überprüfen, ob einige der Zugriffstypen der gebetenen Dateioperation eine Erlaubnis gemäß dem versorgten bitflags des ausgewählten Klasseneigentümers, der Gruppe oder der Welt im Verzeichniszugang der Datei verlangt. Eigentümer, Gruppe und Weltzugriffsrechte sind independant und brauchen sich vermindernde Zugriffsniveaus nicht zu haben. Nur, wenn keiner der gebetenen Zugriffstypen eine Erlaubnis verlangt, wird das Betriebssystem Zugang gewähren, sonst scheitert es.

:If-Mehrbenutzerdatei / Verzeichniskennwort-Sicherheit wird ermöglicht das System wird in dieser Bühne nicht scheitern, aber den Kennwort-Überprüfungsmechanismus für die ausgewählte Erlaubnis-Klasse durchführen, die dem Verfahren ähnlich ist, das oben beschrieben ist. Mit der Mehrbenutzersicherheit geladen viele Dienstprogramme da wird DR DOS 6.0 einen zusätzlichen Parameter zur Verfügung stellen.

:File-Zugriffsrechte bitmap:

:File benennt um verlangen entweder schreiben oder löschen Rechte, IBM 4680 BASIC CHAIN verlangt führen Rechte durch.

• Verlängerter Attribut-Griff (verwendet durch OS/2 1.2 und höher sowie durch Windows NT) in FAT12 und FAT16; die erste Traube der EA Datei oder 0, wenn nicht verwendet. Eine verschiedene Methode, erweiterte Attribute zu versorgen, ist für FAT32 Volumina ausgedacht worden, sieh FAT32. IFS unter dem Ausgleich.
• Hohe zwei Bytes der ersten Traube-Zahl in FAT32; mit den niedrigen am Ausgleich versorgten zwei Bytes.

Die Lagerung der hohen zwei Bytes der ersten Traube in einer Datei auf FAT32 ist teilweise conflictive mit Zugriffsrechten bitmaps.

| -

| Stil = "text-align:Right;" | 0x16

| Stil = "text-align:Right;" | 2|

• Letztes modifiziertes Mal (seit DOS 1.1); sieh Ausgleich für eine Format-Beschreibung.
• Unter Novell DOS, OpenDOS und DR-DOS 7.02 und höher, meint dieser Zugang, dass die Auswischen-Zeit während Dateien oder Verzeichnisse unter DELWATCH 2.00 oder höher löscht. Der letzte modifizierte Zeitstempel wird zu für die mögliche spätere Wiederherstellung kopiert. Sieh Ausgleich für eine Format-Beschreibung.

| -

| Stil = "text-align:Right;" | 0x18

| Stil = "text-align:Right;" | 2|

• Letztes modifiziertes Datum; sieh Ausgleich für eine Format-Beschreibung.
• Unter Novell DOS, OpenDOS und DR-DOS 7.02 und höher, meint dieser Zugang, dass das Auswischen-Datum während Dateien oder Verzeichnisse unter DELWATCH 2.00 oder höher löscht. Die letzte modifizierte Datum-Marke wird zu für die mögliche spätere Wiederherstellung kopiert. Sieh Ausgleich für eine Format-Beschreibung.

| -

| Stil = "text-align:Right;" | 0x1A

| Stil = "text-align:Right;" | 2

| Anfang der Datei in Trauben in FAT12 und FAT16. Niedrige zwei Bytes der ersten Traube in FAT32; mit den hohen am Ausgleich versorgten zwei Bytes.

Einträge mit der Volumen-Etikett-Fahne, Unterverzeichnis ".." das Hinweisen zur FAT12/FAT16-Wurzel und den leeren Dateien mit der Größe 0 sollte die erste Traube 0 haben.

VFAT LFN Einträge ließen auch diesen Zugang auf 0 setzen; auf FAT12 und FAT16 Volumina kann das als ein Teil eines Entdeckungsmechanismus verwendet werden, zwischen während zu unterscheiden, löschen Dateien unter DELWATCH und VFAT LFNs; sieh oben.

| -

| Stil = "text-align:Right;" | 0x1C

| Stil = "text-align:Right;" | 4

| Dateigröße in Bytes. Einträge mit dem Volumen-Etikett- oder Unterverzeichnis-Fahne-Satz sollten eine Größe 0 haben.

VFAT LFN Einträge versorgen nie den Wert hier. Das kann als ein Teil eines Entdeckungsmechanismus verwendet werden, zwischen während zu unterscheiden, löschen Dateien unter DELWATCH und VFAT LFNs; sieh oben.

Für Dateien, die größer sind als 4 GB im Anschluss an das FETT + Vorschlag, hält dieser Zugang nur die Größe des letzten Klotzes der Datei (der Bit 31-0 ist). Die bedeutendsten Bit 37-32 werden im Zugang am Ausgleich versorgt.

| }\

Die mit Sitz in FlexOS Betriebssysteme IBM 4680 OS und IBM 4690 OS unterstützen einzigartige Vertriebsattribute, die in einigen Bit der vorher reservierten Bereiche in den Verzeichniseinträgen versorgt sind:

1. Lokal: Tun Sie nicht verteilte Datei, aber behalten Sie lokalen Kontrolleur nur.
2. Spiegeldatei auf der Aktualisierung: Verteilen Sie Datei zum Server nur, wenn Datei aktualisiert wird.
3. Spiegeldatei auf dem Ende: Verteilen Sie Datei zum Server nur, wenn Datei geschlossen wird.
4. Zusammengesetzte Datei auf der Aktualisierung: Verteilen Sie Datei allen Kontrolleuren, wenn Datei aktualisiert wird.
5. Zusammengesetzte Datei auf dem Ende: Verteilen Sie Datei allen Kontrolleuren, wenn Datei geschlossen wird.

Einige unvereinbare in einigen Betriebssystemen gefundene Erweiterungen schließen ein:

VFAT lange Dateinamen

VFAT Long File Names (LFN) werden auf einem FETTEN Dateisystem mit einem Trick — das Hinzufügen (vielleicht vielfach) zusätzliche Einträge ins Verzeichnis vor dem normalen Dateizugang versorgt. Die zusätzlichen Einträge werden mit dem Volumen-Etikett gekennzeichnet, System, Verborgen und Gelesen schreibt Nur (das Tragen) zu, das eine Kombination ist, die in der MS-DOS-Umgebung nicht erwartet, und deshalb durch MS-DOS-Programme und Drittdienstprogramme ignoriert wird. Namentlich etikettiert ein Verzeichnis, das nur Volumen enthält wird als leer betrachtet und wird erlaubt, gelöscht zu werden; solch eine Situation erscheint, wenn mit langen Namen geschaffene Dateien von der Ebene DOS gelöscht werden. Diese Methode ist der DELWATCH Methode sehr ähnlich, das Volumen-Attribut zu verwerten, um sich während zu verbergen, löschen Dateien für das mögliche zukünftige Unauswischen seit DR DOS 6.0 (1991) und höher.

Ältere Versionen von DOS verwechseln LFN-Namen im Wurzelverzeichnis für das Volumen-Etikett, und werden wahrscheinlich ein falsches Etikett zeigen.

Jeder falsche Zugang kann bis zu 13 UTF-16 Charaktere (26 Bytes) durch das Verwenden von Feldern in der Aufzeichnung enthalten, die Dateigröße oder Zeitstempel enthalten (aber nicht das Starttraube-Feld, für die Vereinbarkeit mit Plattendienstprogrammen, wird das Starttraube-Feld auf einen Wert von 0 gesetzt. Sieh 8.3 Dateinamen für zusätzliche Erklärungen). Bis zu 20 dieser Einträge-Buchstaben 13 können gekettet werden, eine maximale Länge von 255 UTF-16 Charakteren unterstützend.

Nach dem letzten UTF-16 Charakter, zusätzlich zu sein. Die restlichen unbenutzten Charaktere werden damit gefüllt.

LFN Einträge verwenden das folgende Format:

Wenn es vielfache LFN Einträge, erforderlich gibt, einen Dateinamen zu vertreten, erstens kommt der letzte LFN Zugang (der letzte Teil des Dateinamens). Die Folge-Zahl hat auch Bit 6 Satz (das bedeutet den letzten LFN Zugang, jedoch ist es der erste gesehene Zugang, wenn es die Verzeichnisdatei liest). Der letzte LFN Zugang hat die größte Folge-Zahl, die in folgenden Einträgen abnimmt. Der erste LFN Zugang hat Folge Nummer 1. Ein Wert dessen wird verwendet, um anzuzeigen, dass der Zugang gelöscht wird.

Auf FAT12 und FAT16 Volumina, für die Werte prüfend, an, Null zu sein, und an, Nichtnull zu sein, kann verwendet werden, um zwischen VFAT LFNs zu unterscheiden, und während löschen Dateien unter DELWATCH.

Zum Beispiel, wenn wir Dateinamen "Datei mit sehr langem filename.ext haben", würde es wie das formatiert:

Eine Kontrollsumme erlaubt auch Überprüfung dessen, ob ein langer Dateiname den 8.3 Namen vergleicht; solch eine Fehlanpassung konnte vorkommen, wenn eine Datei gelöscht wurde und Verwenden-DOS in derselben Verzeichnisposition erfrischt hat. Die Kontrollsumme wird mit dem Algorithmus unten berechnet. (Bemerken Sie, dass pFCBName ein Zeigestock zum Namen ist, wie es in einem regelmäßigen Verzeichniszugang erscheint, d. h. die ersten acht Charaktere der Dateiname sind, und die letzten drei die Erweiterung sind. Der Punkt ist implizit. Jeder unbenutzte Raum im Dateinamen wird mit Raumcharakteren (ASCII) ausgepolstert. Zum Beispiel, würde "Readme.txt" "" sein.)

nicht unterzeichnete Rotforelle lfn_checksum (const nicht unterzeichnete Rotforelle *pFCBName)

{\

interne Nummer i;

nicht unterzeichnete Rotforelle-Summe = 0;

für (ich = 11; ich; ich-)

resümieren Sie = ((Summe & 1)

geben Sie Summe zurück;

}\</Quelle>

Wenn ein Dateiname nur Kleinbuchstaben enthält, oder eine Kombination eines Kleinbuchstabens basename mit einer Großschrift-Erweiterung, oder umgekehrt ist; und hat keine speziellen Charaktere, und passt innerhalb der 8.3 Grenzen, ein VFAT Zugang wird auf Windows NT und späteren Versionen von Windows wie XP nicht geschaffen. Statt dessen werden zwei Bit im Byte des Verzeichniszugangs verwendet, um anzuzeigen, dass der Dateiname als völlig oder teilweise Klein-betrachtet werden sollte. Spezifisch, hat 4 Mittel-Kleinerweiterung gebissen und hat 3 Kleinbuchstaben basename gebissen, der Kombinationen solcher als "" oder, "" aber nicht "" berücksichtigt. Wenige andere Betriebssysteme unterstützen es. Das schafft ein Umgekehrt-Vereinbarkeitsproblem mit älteren Windows-Versionen (Windows 95 / 98 / 98 SE / ICH), die Vollgroßschrift-Dateinamen sehen, wenn diese Erweiterung verwendet worden ist, und deshalb den Namen einer Datei ändern kann, wenn es zwischen Betriebssystemen, solcher als auf einem USB-Blitz-Laufwerk transportiert wird. Strom 2.6.x Versionen von Linux wird diese Erweiterung anerkennen, wenn er lesen wird (Quelle: Kern 2.6.18 und); die Gestell-Auswahl bestimmt, ob diese Eigenschaft verwendet wird, wenn man schreibt.

Größe-Grenzen

Der FAT12, der FAT16, der FAT16B und die FAT32 Varianten der FETTEN Dateisysteme ließen klare Grenzen auf der Zahl von Trauben und der Zahl von Sektoren pro Traube (1, 2, 4..., 128) stützen. Für den typischen Wert von 512 Bytes pro Sektor:

FAT12 Voraussetzungen: 3 Sektoren auf jeder Kopie von FETT für alle 1,024 Trauben

FAT16 Voraussetzungen: 1 Sektor auf jeder Kopie von FETT für alle 256 Trauben

FAT32 Voraussetzungen: 1 Sektor auf jeder Kopie von FETT für alle 128 Trauben

FAT12 Reihe: 1 bis 4,084 Trauben: 1 bis 12 Sektoren pro Kopie von FETT

FAT16 Reihe: 4,085 bis 65,524 Trauben: 16 bis 256 Sektoren pro Kopie von FETT

FAT32 Reihe: 65,525 bis 268,435,444 Trauben: 512 bis 2,097,152 Sektoren pro Kopie von FETT

FAT12 Minimum: 1 Sektor pro Traube × 1 Trauben = 512 Bytes (0.5 Kilobytes)

FAT16 Minimum: 1 Sektor pro Traube × 4,085 Trauben = 2,091,520 Bytes (2,043 Kilobytes)

FAT32 Minimum: 1 Sektor pro Traube × 65,525 Trauben = 33,548,800 Bytes (32,763 Kilobytes)

FAT12 Maximum: 64 Sektoren pro Traube × 4,084 Trauben = 133,824,512 Bytes ( 127 Mb)

[FAT12 Maximum: 128 Sektoren pro Traube × 4,084 Trauben = 267,694,024 Bytes ( 255 Mb)]

FAT16 Maximum: 64 Sektoren pro Traube × 65,524 Trauben = 2,147,090,432 Bytes (2.047 Mb)

[FAT16 Maximum: 128 Sektoren pro Traube × 65,524 Trauben = 4,294,180,864 Bytes (4.095 Mb)]

FAT32 Maximum: 8 Sektoren pro Traube × 268,435,444 Trauben = 1,099,511,578,624 Bytes (1.024 GB)

FAT32 Maximum: 16 Sektoren pro Traube × 268,173,557 Trauben = 2,196,877,778,944 Bytes (2.046 GB)

[FAT32 Maximum: 32 Sektoren pro Traube × 134,152,181 Trauben = 2,197,949,333,504 Bytes (2.047 GB)]

[FAT32 Maximum: 64 Sektoren pro Traube × 67,092,469 Trauben = 2,198,486,024,192 Bytes (2.047 GB)]

[FAT32 Maximum: 128 Sektoren pro Traube × 33,550,325 Trauben = 2,198,754,099,200 Bytes (2.047 GB)]

</pre>

Legende: 268435444+3 ist, weil FAT32 Version 0 nur 28 Bit in den 32-Bit-Traube-Zahlen, Traube-Zahlen bis zur Fahne schlechte Trauben oder das Ende einer Datei verwendet, beflaggt Traube Nummer 0 eine freie Traube, und Traube Nummer 1 wird nicht verwendet. Ebenfalls 65524+3 ist für FAT16, und 4084+3 ist für FAT12. Die Zahl von Sektoren pro Traube ist eine Macht von 2 Einfügen eines einzelnen Bytes, der kleinste Wert ist 1 , der größte Wert ist 128 . Linien in eckigen Klammern zeigen die ungewöhnliche Traube-Größe 128, und für FAT32 das größere an als notwendige Traube-Größen 32 oder 64.

Weil jeder FAT32 Zugang 32 Bit (4 Bytes) besetzt, verlangt die maximale Zahl von Trauben (268435444) 2097152 FETTE Sektoren für eine Sektor-Größe von 512 Bytes. 2097152 ist, und diesen Wert versorgend, braucht mehr als zwei Bytes. Deshalb hat FAT32 einen neuen 32-Bit-Wert im FAT32-Stiefelsektor sofort im Anschluss an den 32-Bit-Wert für die Gesamtzahl von in der FAT16B Variante eingeführten Sektoren eingeführt.

Die Stiefelrekorderweiterungen haben mit DOS 4.0 Anfang mit magischen 40 oder 41 eingeführt. NORMALERWEISE FETTE Fahrer schauen nur auf die Zahl von Trauben, um FAT12, FAT16 und FAT32 zu unterscheiden: Die menschlichen lesbaren Schnuren, die die FETTE Variante in der Stiefelaufzeichnung identifizieren, werden ignoriert, weil sie nur für Medien bestehen, die mit DOS 4.0 oder später formatiert sind.

Bestimmung der Zahl von Verzeichniseinträgen pro Traube ist aufrichtig, jeder Zugang besetzt 32 Bytes, das läuft auf 16 Einträge pro Sektor für eine Sektor-Größe von 512 Bytes hinaus. DOS 5 / Befehl entfernt die Initiale "" (dieses Verzeichnis) und "" (Elternteilverzeichnis) Einträge in Unterverzeichnissen direkt, deshalb ist Sektor-Größe 32 auf einer RAM-Platte für FAT12 möglich, aber verlangt 2 oder mehr Sektoren pro Traube. Ein FAT12-Stiefelsektor ohne DOS 4 Erweiterungen brauchen 29 Bytes vor der ersten unnötigen FAT16B 32-Bit-Zahl von verborgenen Sektoren, verlässt das drei Bytes für (auf einer RAM-Platte unbenutzt) Stiefelcode und die Magie am Ende aller Stiefelsektoren. Auf Windows NT ist die kleinste unterstützte Sektor-Größe 128.

Auf Windows NT Betriebssysteme die FORMAT-Befehl-Optionen und entsprechen der maximalen Traube-Größe (128) mit einer Sektor-Größe 1024 und 2048 beziehungsweise. Für die allgemeine Sektor-Größe 512 Erträge 128 Sektoren pro Traube.

Beide Ausgaben jedes ECMA-107 und ISO/IEC 9293 geben eine Zahl von Max Cluster an, die durch die Formel bestimmt ist, und bestellen Traube-Zahlen bis zu 4086 (FAT12) und spätere 65526 (FAT16) für die zukünftige Standardisierung vor.

EFI des Microsofts FAT32 Spezifizierung stellt fest, dass jedes FETTE Dateisystem mit weniger als 4085 Trauben FAT12, sonst jedes FETTE Dateisystem mit weniger als 65525 Trauben ist, ist FAT16, und sonst ist es FAT32. Der Zugang für die Traube 0 am Anfang des FETTES muss zum im BPB gefundenen Mediadeskriptor-Byte identisch sein, wohingegen der Zugang für die Traube 1 den Wert des Endes der Kette widerspiegelt, der durch den formatter für Traube-Ketten (oder) verwendet ist. Die Einträge für die Traube Nummern 0 und 1 enden an einer Byte-Grenze sogar für FAT12 z.B für den Mediadeskriptor.

Die erste Datentraube ist 2, und folglich bekommt die letzte Traube Zahl. Das läuft auf Datentraube Nummern 2... 4085 für FAT12, 2 hinaus... 65525 für FAT16, und 2... 268435445 für FAT32.

Die einzigen verfügbaren für die zukünftige Standardisierung vorbestellten Werte sind deshalb (FAT12) und (FAT16). Wie bemerkt, unter "weniger als 4085" wird auch für Linux implemementations verwendet, oder wie die FETTE Spezifizierung des Microsofts sagt:

Zersplitterung

Das FETTE Dateisystem enthält eingebaute Mechanismen nicht, die kürzlich schriftliche Dateien davon abhalten, gestreut über die Teilung zu werden. Auf Volumina, wo Dateien geschaffen und oft oder ihre häufig geänderten Längen gelöscht werden, wird das Medium zunehmend gebrochen mit der Zeit werden.

Während das Design des FETTEN Dateisystems keinen organisatorisch oben in Plattenstrukturen verursacht oder den Betrag des freien Abstellraums mit vergrößerten Beträgen der Zersplitterung reduziert, weil es mit der Außenzersplitterung, die Zeit vorkommt, die erforderlich ist, zu lesen und zu schreiben, dass gebrochene Dateien zunehmen werden, weil das Betriebssystem den Traube-Ketten im FETT (mit Teilen wird folgen müssen, die ins Gedächtnis zuerst insbesondere auf großen Volumina geladen werden) und die entsprechenden Daten physisch lesen müssen, die über die ganzen mittleren abnehmenden Chancen für den auf niedriger Stufe Block-Gerät-Fahrer gestreut sind, Mehrsektor-Platteneingabe/Ausgabe durchzuführen oder größere DMA-Übertragungen zu beginnen, dadurch effektiv Eingabe/Ausgabe-Protokoll oben vergrößernd, sowie Arm-Bewegung und Kopf Zeiten innerhalb des Laufwerks setzen. Außerdem werden Dateioperationen langsamer mit der wachsenden Zersplitterung werden, weil sie zunehmend länger für das Betriebssystem nimmt, um Dateien oder freie Trauben zu finden.

Andere Dateisysteme, z.B. HPFS oder exFAT, verwenden Sie freien Raum bitmaps, die verwendete und verfügbare Trauben anzeigen, die dann schnell nachgeschlagen werden konnten, um freie aneinander grenzende Gebiete zu finden. Eine andere Lösung ist die Verbindung aller freien Trauben in eine oder mehr Listen (wie in Dateisystemen von Unix getan wird). Statt dessen muss das FETT als eine Reihe gescannt werden, um freie Trauben zu finden, die zu Leistungsstrafen mit großen Platten führen können.

Tatsächlich sind das Suchen für Dateien in großen Unterverzeichnissen oder die Computerwissenschaft des freien Speicherplatzes auf FETTEN Volumina eine vom grössten Teil der Quelle intensive Operationen, weil es das Lesen der Verzeichnistische oder sogar des kompletten FETTES geradlinig verlangt. Seit der Summe von Trauben und der Größe ihrer Einträge im FETT war noch auf FAT12 und FAT16 Volumina klein, das konnte noch auf FAT12 und FAT16 Volumina den größten Teil der Zeit geduldet werden, denkend, dass die Einführung von hoch entwickelteren Plattenstrukturen auch die Kompliziertheit und den Speicherfußabdruck der echten Weise Betriebssysteme mit ihren minimalen Gesamtspeichervoraussetzungen von 128 Kilobytes oder weniger vergrößert hätte (solcher als mit DOS), für den FETT entworfen und ursprünglich optimiert worden ist.

Mit der Einführung von FAT32, suchen Sie lange und scannen Sie Zeiten ist mehr offenbar besonders auf sehr großen Volumina geworden. Eine mögliche Rechtfertigung, die von Raymond Chen des Microsofts angedeutet ist, für die maximale Größe von FAT32 auf Windows geschaffenen Teilungen zu beschränken, war die Zeit, die erforderlich ist, eine "" Operation durchzuführen, die immer den freien Speicherplatz als die letzte Linie zeigt. Das Anzeigen dieser Linie hat länger und länger als die Zahl von vergrößerten Trauben genommen. FAT32 hat deshalb einen speziellen Dateisysteminformationssektor eingeführt, wo der vorher geschätzte Betrag des freien Raums über Macht-Zyklen bewahrt wird, so dass der freie Raumschalter nur wiederberechnet werden muss, wenn formatiertes Medium eines absetzbaren FAT32 vertrieben wird, ohne es zuerst unzubesteigen, oder wenn das System ausgeschaltet wird, ohne das Betriebssystem, ein Problem richtig zu schließen, das mit pre-ATX-style PCs, auf einfachen DOS-Systemen und einigen batterieangetriebenen Verbrauchsgütern größtenteils sichtbar ist.

Mit den riesigen Traube-Größen (16 Kilobytes, 32 Kilobytes, 64 Kilobytes) gezwungen durch größere FETTE Teilungen, hängt die innere Zersplitterung in der Form der Speicherplatz-Verschwendung durch die Datei locker wegen der Traube über (weil Dateien selten genaue Vielfachen der Traube-Größe sind), fängt an, ein Problem ebenso besonders zu sein, wenn es sehr viele kleine Dateien gibt.

Verschiedene Optimierungen und Kniffe zur Durchführung von FETTEN Dateisystemfahrern, Block-Gerät-Treibern und Plattenwerkzeugen sind ausgedacht worden, um zu siegen, die meisten Leistungsengpässe im Dateisystem erben Design, ohne das Lay-Out der Strukturen auf der Platte ändern zu müssen. Sie können in online- und Off-Linemethoden und Arbeit geteilt werden, indem sie versuchen, Zersplitterung im Dateisystem an erster Stelle zu vermeiden, Methoden einsetzend, mit vorhandener Zersplitterung, und durch die Umstellung besser fertig zu werden und die Strukturen auf der Platte optimierend. Mit Optimierungen im Platz kann die Leistung auf FETTEN Volumina häufig die von hoch entwickelteren Dateisystemen in praktischen Drehbüchern erreichen, während sie zur gleichen Zeit den Vorteil behält, sogar auf sehr kleinen oder alten Systemen zugänglich zu sein.

DOS 3.0 und wird höher Speicherplatz von gelöschten Dateien für neue Zuteilungen nicht sofort wiederverwenden, aber stattdessen für den vorher unbenutzten Raum vor dem Starten suchen, Speicherplatz vorher gelöschter Dateien ebenso zu verwenden. Das hilft nicht nur, die Integrität von gelöschten Dateien für so lange wie möglich aufrechtzuerhalten, sondern auch beschleunigt Dateizuteilungen und vermeidet Zersplitterung seitdem nie, bevor zugeteilter Speicherplatz immer ungebrochen wird.

DOS vollbringt das durch das Halten eines Zeigestocks zur letzten zugeteilten Traube auf jedem bestiegenen Volumen im Gedächtnis und Anfang, der nach freiem Raum von dieser Position aufwärts statt am Anfang des FETTES sucht, weil es noch durch DOS 2.x getan wurde. Wenn das Ende des FETTES erreicht wird, würde es sich ringsherum einhüllen, um die Suche am Anfang des FETTES fortzusetzen, bis entweder freier Raum gefunden worden ist oder die ursprüngliche Position, ist wieder erreicht worden, ohne freien Raum gefunden zu haben. Diese Zeigestöcke werden initialisiert, um zum Anfang der FETTE danach bootup hinzuweisen, aber auf FAT32 Volumina, DOS 7.1 und wird höher versuchen, die letzte Position vom FS Informationssektor wiederzubekommen.

Dieser Mechanismus wird jedoch vereitelt, wenn eine Anwendung häufig löscht und vorläufige Dateien erfrischt, weil das Betriebssystem dann versuchen würde, die Integrität von leeren Daten aufrechtzuerhalten, die effektiv mehr Zersplitterung schließlich verursachen. In einigen DOS-Versionen kann der Gebrauch einer speziellen API-Funktion, vorläufige Dateien zu schaffen, verwendet werden, um dieses Problem zu vermeiden.

Zusätzlich werden Verzeichniseinträge von gelöschten Dateien seit DOS 3.0 gekennzeichnet. DOS 5.0 und wird höher anfangen, diese Einträge nur wiederzuverwenden, als vorher unbenutzte Verzeichniseinträge im Tisch verbraucht worden sind und das System den Tisch selbst würde sonst ausbreiten müssen.

Seit DOS 3.3 stellt das Betriebssystem Mittel zur Verfügung, die Leistung von Dateioperationen mit FASTOPEN durch das Nachgehen die Position kürzlich geöffneter Dateien oder Verzeichnisse in verschiedenen Formen von Listen (MS-DOS/PC DOS) oder Hash-Tabellen (DR-DOS) zu verbessern, das abnehmen kann, Datei suchen und öffnen Zeiten bedeutsam. Vor DOS muss 5.0 spezielle Sorge genommen werden, wenn man solche Mechanismen in Verbindung mit der Plattendefragmentierungssoftware verwendet, die das Dateisystem oder die Plattenfahrer umgeht.

Windows NT wird Speicherplatz Dateien auf FETT im Voraus zuteilen, große aneinander grenzende Gebiete auswählend, aber im Falle eines Misserfolgs werden Dateien, die angehangen wurden, größer scheinen, als sie jemals in mit vielen zufälligen Daten am Ende geschrieben wurden.

Andere Mechanismen auf höchster Ebene können darin lesen und größere Teile oder das ganze FETT auf dem Anlauf oder auf Verlangen wenn erforderlich, bearbeiten und dynamisch Baumdarstellungen im Gedächtnis der von den Strukturen auf der Platte verschiedenen Dateistrukturen des Volumens aufbauen. Das, auf Volumina mit vielen freien Trauben, kann noch weniger Gedächtnis besetzen als ein Image des FETTES selbst. Insbesondere auf hoch gebrochenen oder gefüllten Volumina, sucht werden viel schneller als mit dem geradlinigen Ansehen über das wirkliche FETT, selbst wenn ein Image des FETTES im Gedächtnis versorgt würde. Außerdem auf dem logisch hohen Niveau von Dateien und Traube-Ketten statt auf dem Sektor- oder Spur-Niveau funktionierend, wird es möglich, etwas Grad der Dateizersplitterung an erster Stelle zu vermeiden oder lokale Dateidefragmentierung und Umstellung von Verzeichniseinträgen auszuführen, die auf ihren Namen oder Zugriffsmustern im Vordergrund gestützt sind.

Einige der wahrgenommenen Probleme mit der Zersplitterung von FETTEN Dateisystemen ergeben sich auch aus Leistungsbeschränkungen der zu Grunde liegenden Block-Gerät-Fahrer, die mehr sichtbar werden, ist das kleinere Gedächtnis für die Sektor-Pufferung und Spur blocking/deblocking verfügbar:

Während Einzelprogrammverarbeitungs-DOS Bestimmungen für den Mehrsektor hatte, liest und Spur blocking/deblocking, das Betriebssystem und die traditionelle PC-Festplatte-Architektur (nur eine hervorragende Bitte des Eingangs/Produktion auf einmal und keine DMA-Übertragungen) haben ursprünglich Mechanismen nicht enthalten, die Zersplitterung durch das asynchrone Vorholen folgender Daten erleichtern konnten, während die Anwendung die vorherigen Klötze bearbeitete. Solche Eigenschaften sind verfügbar später geworden. Spätere DOS-Versionen haben auch eingebaute Unterstützung für die Sektor-Pufferung des Blicks vorn zur Verfügung gestellt und sind mit dynamisch loadable Plattenverstecken-Programme gekommen, die auf dem physischen oder logischen Sektor-Niveau häufig arbeiten, EMS oder XMS Gedächtnis verwertend und manchmal anpassungsfähige Verstecken-Strategien oder sogar Lauf in der geschützten Weise durch DPMS oder das Bemänteln zur Verfügung stellend, um Leistung durch die Gewinnung direkten Zugangs zu den versteckten Daten im geradlinigen Gedächtnis aber nicht durch herkömmliches DOS APIs zu vergrößern.

Schreiben Sie - hinter dem Verstecken wurde häufig standardmäßig mit der Software von Microsoft (wenn anwesend) gegeben das Problem des Datenverlustes im Falle eines Macht-Misserfolgs oder Unfalls, gemacht leichter durch den Mangel am Hardware-Schutz zwischen Anwendungen und dem System nicht ermöglicht.

Gesetzliche Probleme

Das Genehmigen

Microsoft hat sich beworben, und, wurde eine Reihe von Patenten für Schlüsselteile des FETTEN Dateisystems Mitte der 1990er Jahre gewährt. Fast allgemein vereinbar und gut verstanden seiend, wird FETT oft als ein Austausch-Format für Blitz-Medien gewählt, die in Digitalkameras und PDAs verwendet sind.

Am 3. Dezember 2003 hat Microsoft bekannt gegeben, dass es Lizenzen für den Gebrauch seiner FETTEN Spezifizierung und "vereinigten geistigen Eigentums", auf Kosten eines Königtums von 0.25 US$ pro Einheit verkauft mit einem maximalen Königtum von 250,000 $ pro Lizenzvertrag anbieten würde.

Zu diesem Zweck hat Microsoft vier Patente auf dem FETTEN Dateisystem als die Basis seiner Ansprüche des geistigen Eigentums zitiert. Alle vier gehören langen Dateiformaten zu in Windows 95 zuerst gesehenem FETT:

• : Methode und System, für auf eine Datei mit Dateinamen zuzugreifen, die verschiedene Dateiname-Formate haben. Abgelegt am 6. Juli 1992. Das hat ein Mittel des Erzeugens und Verbindens eines kurzen, 8.3 Dateinamens mit lange ein (zum Beispiel, "Microsoft.txt" mit "MICROS~1.TXT") und ein Mittel bedeckt, widerstreitende kurze Dateinamen (zum Beispiel, "MICROS~2.TXT" und "MICROS~3.TXT") aufzuzählen.
• : Raum der gemeinsamen Bezeichnung für lange und kurze Dateinamen. Abgelegt für am 1995-04-24. Das bedeckt die Methode, zusammen vielfache genannte 8.3 Konsekutivverzeichniseinträge zu ketten, um lange Dateinamen, mit einigen der Einträge besonders gekennzeichnet zu halten, um ihre verwirrenden älteren, langen dateinamenunbewussten FETTEN Durchführungen zu verhindern.
• Das Öffentliche Offene Fundament hat erfolgreich dieses Patent herausgefordert; die Ansprüche wurden am 2004-09-14 wegen der vorherigen Enthüllung der geforderten Techniken in Patenten zurückgewiesen und. Diese Entscheidung wurde später vom Patentamt am 2006-01-10 gestürzt.
• : Raum der gemeinsamen Bezeichnung für lange und kurze Dateinamen. Abgelegt am 1996-09-05. Das ist 5,579,517 sehr ähnlich.
• Das Öffentliche Offene Fundament hat erfolgreich dieses Patent (USPTO) herausgefordert; der USPTO hat dieses Patent am 2005-10-05 zurückgewiesen, mit der Begründung, dass "die sechs Bevollmächtigter-Namen falsch waren". Diese Entscheidung wurde auch später vom Patentamt am 2006-01-10 gestürzt.
• : Methode und System, für einen Raum der gemeinsamen Bezeichnung für lange und kurze Dateinamen in einem Betriebssystem zu bieten. Abgelegt am 1997-01-28. Das erhebt Ansprüche auf den verwendeten Methoden, wenn Windows 95, Windows 98 und Windows ME lange Dateinamen zu ihrer MS-DOS-Vereinbarkeitsschicht ausstellen. Es scheint nicht, irgendwelche Durchführungen von non-Microsoft FAT zu betreffen.

Im EFI FAT32 Spezifizierung gewährt Microsoft spezifisch mehrere Rechte, die viele Leser als Erlauben von Betriebssystemverkäufern interpretiert haben, FETT durchzuführen.

Microsoft ist nicht die einzige Gesellschaft, um sich um Patente um Teile des FETTEN Dateisystems beworben zu haben. Andere Patente, die FETT betreffen, schließen ein:

• : System, um zuzugreifen, hat Gegenstand-Attribut (EA) Daten durch den Dateinamen oder die EA-Griff-Verbindungen in Pfad-Tischen erweitert. Abgelegt am 1990-09-25 von Barry A. Feigenbaum und Felix Miro von IBM erhebt das Ansprüche auf den Methoden, die durch OS/2, Windows NT und Linux verwendet sind, um erweiterte Attribut-Daten in den EA "DATEN zu versorgen. SF" Datei.

Bitte

Da es weit verbreiteten Aufruf nach diesen nochmals zu prüfenden Patenten gab, hat das Öffentliche Offene Fundament (PUBPAT) Beweise dem US-Patent- und Handelsbüro (USPTO) das Diskutieren der Gültigkeit dieser Patente, einschließlich vorheriger Kunstverweisungen von Xerox und IBM vorgelegt. Der USPTO hat zugegeben, dass die Beweise "wesentliche neue Frage [s] der Patentierfähigkeit," aufgebracht haben und eine Untersuchung der Gültigkeit der FETTEN Patente des Microsofts geöffnet haben.

Am 2004-09-30 hat der USPTO alle Ansprüche, gestützt in erster Linie auf durch PUBPAT zur Verfügung gestellten Beweisen zurückgewiesen. Dan Ravicher, der verantwortliche Direktor des Fundaments, hat gesagt, "Das Patentamt hat einfach bestätigt, was wir bereits für einige Zeit jetzt gewusst haben, ist das FETTE Patent des Microsofts gefälscht."

Gemäß der PUBPAT Presseinformation, "Hat Microsoft noch die Gelegenheit, auf die Verwerfung des Patentamtes zu antworten. Gewöhnlich sind Drittbitten um die Nachprüfung, wie durch PUBPAT abgelegte diejenige, darin erfolgreich, das unterworfene Patent entweder eingeengte oder völlig widerrufene ungefähr 70 % der Zeit zu haben."

Am 2005-10-05 hat das Patentamt bekannt gegeben, dass, im Anschluss an den Nachprüfungsprozess, es wieder alle Ansprüche von offenen 5,579,517 zurückgewiesen hatte, und es zusätzlich ungültig gefunden hat mit der Begründung, dass das Patent falsche Bevollmächtigte hatte.

Schließlich am 2006-01-10 hat das Patentamt entschieden, dass Eigenschaften der Durchführung des Microsofts des FETTEN Systems "neuartig und nichtoffensichtlich waren", beide früheren Nichtendentscheidungen umkehrend.

Patentverletzungsrechtssachen

Im Februar 2009 hat Microsoft eine Patentverletzungsklage gegen TomTom eingereicht, der behauptet, dass die Gerät-Schöpfer-Produkte in mit dem FAT32 Dateisystem verbundene Patente eingreifen. Da einige Produkte von TomTom auf Linux basieren, hat das das erste Mal gekennzeichnet, dass Microsoft versucht hat, seine Patente gegen die Plattform von Linux geltend zu machen. Die Rechtssache wurde aus dem Gericht im nächsten Monat mit einer Abmachung gesetzt, dass Microsoft Zugang zu vier der Patente von TomTom gegeben wurde, dass TomTom Unterstützung für das FAT32 Dateisystem von seinen Produkten fallen lassen wird, und dass in der Rückkehr Microsoft nicht gerichtliches Vorgehen gegen TomTom für die fünfjährige Dauer der Ansiedlungsabmachung sucht.

Im Oktober 2010 hat Microsoft eine Patentverletzungsklage gegen Motorola eingereicht, der behauptet, dass mehrere Patente (einschließlich zwei der FAT32 Dateisystempatente) für den Gebrauch im Androiden Betriebssystem nicht lizenziert wurden. Sie haben auch eine Beschwerde zum ITC vorgelegt.

Entwickler der offenen Quellsoftware haben entwickelt Methoden haben vorgehabt, die Patente des Microsofts zu überlisten.

Siehe auch

• Vergleich von Dateisystemen
• Laufwerk-Brief-Anweisung
• Liste von Dateisystemen
• Vor der Transaktion sicheres FETTES Dateisystem

Zeichen

</Verweisungen>

Außenverbindungen

• ECMA-107 Volumen und Dateistruktur von Plattenpatronen für den Informationsaustausch, der zu ISO/IEC 9293 identisch ist.
• Microsoft Extensible Firmware Initiative FAT32 File System Specification, FETT: Allgemeine Übersicht des Formats auf der Platte
• Das Verstehen von FAT32 Dateisystemen (erklärt für eingebettete firmware Entwickler)
• Das Verstehen von FETT einschließlich viel Infos über LFNs
• Ausführliche Erklärung des FETTEN Stiefelsektors: Microsoft Knowledge Base Article 140418
• Beschreibung des FAT32 Dateisystems: Microsoft Knowledge Base Article 154997
• FAT12/FAT16/FAT32-Dateisystemdurchführung für *nix: Schließt libfat Bibliotheken und fusefat, ein SICHERUNGS-Dateisystemfahrer ein
• MS-DOS: Verzeichnis und Unterverzeichnis-Beschränkungen: Microsoft Knowledge Base Article 39927
• Übersicht von FETT, HPFS und NTFS Dateisystemen: Microsoft Knowledge Base Article 100108
• Volumen und Dateigröße-Grenzen von FETTEN Dateisystemen: Microsoft Technet
• Microsoft TechNet: Eine kurze und unvollständige Geschichte von FAT32 durch Raymond Chen
• FAT32 Formatter: Erlaubt, Volumina zu formatieren, die größer sind als mit FAT32 unter Windows 2000, Windows XP und Windows-Aussicht
• Fdisk erkennt volle Größe von Festplatten nicht an, die größer sind als: Microsoft Knowledge Base Article 263044.
• Windows von Microsoft XP: FAT32 Dateisystem. Kopie, die vom Internetarchiv Wayback Maschine eines Artikels mit der Zusammenfassung von Grenzen in FAT32 gemacht ist, der verfügbar auf der Website von Microsoft nicht länger ist.
• Sehlay-Out der Straße FAT16
• FETTES Dateisystem