Diskussion:File Allocation Table

Realisierung von Verzeichnissen?

Was mir nach der Lektüre des Artikel nicht ganz klar geworden ist: Klar, man könnte einen Eintrag in das Stammverzeichnis setzen (Typ: Directory), aber woher weiß man dann, welche Dateien zu dem Verzeichnis gehören? --77.7.10.95 12:35, 18. Dez. 2007 (CET)

Habe jetzt nochmal in der Englischen Wikipedia nachgelesen. Scheinbar gibt es ein Root-Directory, in dem sich dann andere Verzeichnisse befinden können (und in diesen Verzeichnissen können wieder Verzeichnisse sein usw.). Ein neues Verzeichnis hat dann auch eine neue Verzeichnistabelle. Das Root-Verzeichnis wird im Boot-Sektor der jeweiligen Partition vermerkt.

Das kommt bei dem Artikel hier aber leider nicht so raus (wenn es wirklich so ist!), d.h. er müsste IMO überarbeitet werden (das traue ich mir aber bei meinem Kenntnisstand aber nicht zu). --77.7.10.95 12:55, 18. Dez. 2007 (CET)

Max. Partitionsgröße

Bin trotz Info-Studiums auf diesem Gebiet recht unkundig. Ich verstehe nicht, warum im Artikel als max. Größe 2 TB angegeben werden. Immerhin ist es bei 2^28 Clustern und einer Clustergröße von 32 * 1024 Byte nach meiner Rechnung möglich, max. 8 TB bzw. TiB Partitionen einzurichten.

Im Gegensatz zu FAT 16, das Win 2k und NT afaik auch mit einer max. Clustergröße von 64 KB nutzen können, ist dies meines Wissens mit FAT 32 nicht oder nur theoretisch möglich.

Deshalb bitte ich um Erklärung, weshalb 2 TB als max. Größe angegeben werden. Danke! tomiwolf

Fdisk

Zitat: "Unter Windows 2000 und Nachfolgern darf der Benutzer mit dem eingebauten Programm "Formatieren" ..."
Meine Frage:Ist mit diesem Programm das Programm fdisk gemeint? Hbtechnic 13:23, 15. Dez 2005 (CET)

Mehr oder weniger. Seit Windows 2000 gibts bei Microsoft Windows ein grafisches Frontend zum partitionieren von Laufwerken. Mit dem Formatieren hat das eigentliche Partitionieren (was vor allem Unix-fdisk-Derivate machen, das Windows 9x-fdisk allerdings schon) entgegen allen Laienwissens wenig zu tun.

Grüße, --Benji 16:05, 11. Feb. 2007 (CET)

Den grafischen Festplattenmanager gibt es unter allen NT-Systemen (bestätigen kann ich das zumindest ab NT 3.51, mein ältestes NT-System, das ich selbst installiert habe), "fdisk" hingegen ist das DOS-Pendant für DOS und DOS-basierende Windowssysteme. FAT 16 ist unter NT 4.0 sogar bis 4 GB möglich, aber nicht als Kompatibilitätsoption, sondern weil dieses OS noch kein NTFS formatieren kann, sondern selbst beim installieren auf NTFS nur eine FAT anlegt und diese beim Neustart konvertiert. Und dass ab Win 2k eine künstliche Beschränkung auf 32 GB installiert ist (die Windows 9x unter fdisk nicht kennt), wird ja bereits an anderer Stelle erwähnt. -- Qhx 15:00, 2. Aug. 2008 (CEST)

Sonstiges 1

Hi, in diesem artikel ist die rede von einem bereich der Bootsektor benannt wird. sollte man das nicht noch Master Boot Record nennen?

Nein, der Master Boot Record einer Festplatte ist etwas anderes als der Bootsektor einer Partition. Siehe verlinkte Artikel. --RokerHRO 13:30, 6. Apr. 2008 (CEST)

Sonstiges 2

Tach,

Microsoft gibt auf seinen Seiten eine maximale Kapazität von 2TB (TiB?) für FAT32 an. dabei wird aber von einer Standard-Clustergröße von 4KiByte ausgegangen. Auf der selben Seite steht, dass Clustergrößen über 32KiByte zu Programmfehlern führen. Daraus läßt sich meiner Meinung nach folgern, dass 64KiByte-Cluster ebenfalls möglich wären, woraus sich eine theoretische mögliche Kapazität von sogar 16Tibyte ergäbe. Allerdings würde es wohl nur wenig Sinn machen ein solches Medium auf FAT32 zu formatieren.

Interessanter Weise ist laut Microsoft 2^28 = 268.435.445 anstatt 268.435.456...

Moin,

ich hab' mich gerade im Rahmen des Studiums ausführlich mit FATs beschäftigt und halte diese Artikel bei allem nötigen Respekt für ziemlichen Müll. Ich werde mich nächste Woche mal dransetzen und den Artikel von Grund auf überarbeiten, bzw. neu schreiben. --Liberty83 00:17, 22. Okt 2005 (CEST)

P.S.: Für Anregungen bin ich immer zu haben.

bei den Einheiten ist das "i" bestimmt überflüssig, von FAT32 habe ich andere Sachen gehört... z.B., dass maximal 180GB Partitionsgöße unterstützt werden oder Dateien dürfen bis zu nur 2 GB groß werden, wie gesagt aber nur gehört, Gruß --194.95.177.124 11:33, 19. Jul 2004 (CEST)

 Mit FAT 32 kann mann Partitionen bis 2TByte formatieren. 
http://www.hardware-extrem.de/index.php?option=content&task=view&id=11&Itemid=31 --AronX 16:46, 20. Okt 2004 (CEST)

ok hat sich mit dem "i" erledigt, meine Unwisseneheit: http://www.heise.de/newsticker/meldung/4987 --194.95.177.124 11:39, 19. Jul 2004 (CEST)

FAT12

„Die verwaltbare Kapazität ist auf 2 MiB beschränkt“ – „Die Partitionsgröße muss kleiner als 16 MiB sein.“ ist das ein Widerspruch? Wenn damit wirklich gemeint sein soll, dass man auf einer 16-MiB-Partition ein 2-MiB-Dateisystem und 14 MiB verschenkten Platz einrichten soll, so bitte ich darum, die Stelle entsprechend zu überarbeiten. Oder kann man doch Cluster einrichten? -- Pemu 16:30, 26. Sep 2005 (CEST)

"Die verwaltbare Kapazität ist auf 2 MiB beschränkt." - Wieso gab's da mal, wenn auch nie sonderlich weit verbreitet, 2,88 MB-Disketten? Das mit der ausschließlichen Clustergröße von 512 Byte kann doch so wohl nicht stimmen!

Ok, um das ganze mal aufzuklären:

• FAT12 kann maximal 4096 cluster addressieren (wegen der 12 Bit) und die auch in allen verwendeten varianten nur mit 4096 bytes pro cluster. Macht in summe 16777216 Bytes, also 16MB. Wie man das von anderen FAT Dateisystemen aber so kennt, kann man hier nur wesentlich kleinere Dateien speichern, nämlich welche der Grösse 2MB. Wer das nicht glaubt kann gerne mal zu mir kommen, ich habe noch einen 80186er hier stehen, da läuft MSDOS 2.11 drauf.

Das mit den 4096 Clustern stimmt (wenn wir mal die paar reservierten Cluster in dieser Überschlagsrechnung unterschlagen), aber Du gehst in Deiner Rechnung von einer festen Clustergröße von 4 KB und 512 Bytes pro physikalischen Sektor aus. Diese Annahme ist aber im allgemeinen Fall unzulässig und bezieht sich nur auf die Verhältnisse, wie sie bei IBM-kompatiblen Rechnern mit BIOS-Int 13h üblich waren und sind. Es gab damals aber noch jede Menge andere Rechner, die zwar MS-DOS kompatibel waren, nicht aber IBM PC-kompatibel. Darin waren z.T. auch ganz andere physikalische Sektorgrößen üblich. Das hat zwar nicht in allen DOS-Versionen funktioniert, aber im Prinzip war DOS schon immer dafür ausgelegt, mit beliebigen physikalischen Sektorgrößen zwischen 32 Bytes und 32 KB Größe zu arbeiten (üblich waren aber eigentlich nur 128 Bytes bis 8 KB). Die Blockgerätetreiber melden ja bei der Initialisierung die jeweils benötigte Sektorgröße (meist eben 512 Bytes bei den internen Treibern) und DOS kann auch die Initialisierung eines Treibers verweigern, wenn es die vom Treiber geforderte Sektorgröße nicht unterstützt. Ansonsten merkt sich DOS die von einem Treiber größte benötigte physikalische Sektorgröße und baut dann nach dem Abarbeiten der CONFIG.SYS seine internen Datenstrukturen so auf, daß Diskbuffer in der benötigten Maximalgröße für mindestens einen physikalischen Sektor bereitgestellt werden. Nach oben hin Richtung Dateisystem arbeitet DOS nur mit logischen Sektoren (in linearer Adressierung) in dieser während der Bootphase dynamisch angepaßten Größe. Bei Blockdevices, die kleinere physikalische Sektorgrößen benötigen, werden einfach entsprechend viele physikalische Sektoren zu einem sog. logischen Sektor zusammengefaßt. Durch den dabei für DOS-Verhältnisse sehr groß werdenden Disk-Buffer sind große logische Sektorgrößen nicht gerade effizient, aber immerhin ist es auf diese Weise möglich, mit Blockgeräten unterschiedlichster Sektorgrößen zusammenzuarbeiten.

Als nun die Festplatten größer wurden und FAT16B mit seinen 32-bittigen Sektoreinträgen noch nicht existierte, ließen sich verschiedene DOS-OEMs andere Mechanismen einfallen, um trotzdem größere Platten anzusprechen. So gab es allein mehr als zehn verschiedene MS-DOS OEM-Varianten, bei denen FAT12- und FAT16-Laufwerke mit sog. logically sectored FATs benutzt wurden, die eben gerade mit künstlich vergrößerten physikalischen Sektoren arbeiteten, und die die Adressierungsgrenzen von FAT12 und FAT16 dadurch umgingen, daß einfach die Sektorgröße entsprechend vergrößert wurde. Dem Dateisystemtreiber, der nur auf Basis dieser logischen Sektoren arbeitet, ist das völlig egal, wenn die unteren Schichten das entsprechend in die richtige Zahl physikalischer Sektoren übersetzen. Diese logically sectored FATs hatten in der Regel auch nicht den Partitionstyp 01h oder 04h, damit es nicht zu Kompatibilitätsproblemen mit den Standardtypen kam, denn nicht alle MS-DOS-Ausgaben beherrschten diese Sektorgrößenanpassung fehlerfrei.

Andere MS-DOS OEM-Varianten lösten das Problem mit der Ansteuerung großer Festplatten, indem im MBR nicht nur die üblichen 4 primären Partitionen definiert werden konnten, sondern bis zu 16 Stück. Es gab DOS-Versionen, die bis zu 128 Diskettenlaufwerke und bis zu 128 virtuelle Festplatten unterstützen und wenn die Laufwerksbuchstaben nicht reichten, ging es mit Sonderzeichen oder Zahlen weiter (Stichwort: LASTDRIVE=32). Erst mit der Lockerung des Verhältnisses zwischen Clustern und Sektoren, der Einführung von FAT16B und der von logischen Laufwerken in erweiterten Partitionen hörte dieser Wildwuchs auf und die physikalische Sektorgröße konnte wieder auf effiziente 512 Bytes reduziert werden - nicht IBM-kompatible PCs waren zu diesem Zeitpunkt kaum noch vertreten. Wenn Du ausprobieren willst, welche Sektorgrößen verschiedene DOS-Varianten unterstützen, empfehle ich ein paar Experimente mit RAM-Disktreibern wie TDSK, die zur Laufzeit in der Größe anpaßbar sind. Insbesondere DR-DOS ist da extrem flexibel und schluckt praktisch alles an Geometrieparametern, was denkbar ist, wohingehen MS-DOS sich hier als wesentlich unflexibler erweist. Aber zurück zum Thema:

Nehmen wir als physikalische Sektorgröße 8 KB an und als Clustergröße ebenfalls (wie gesagt, das Verhältnis Sektoren/Cluster war damals noch nicht so flexibel wählbar wie heute), dann kommen wir mit FAT12 auf 32 MB (was deshalb oft als Limit zitiert wird). Das theoretische Limit mit 32 KB-Clustern läge sogar bei 128 MB, mit 64 KB-Clustern bei 256 MB. Meines Wissens war damals aber die größte tatsächlich verwendete Sektor- und damit auch Clustergrenze 8 KB. Bei FAT16 käme man damit auf die ebenfalls oft zitierten 512 MB. Soweit ich weiß, wurden solch große Laufwerke aber erst verwendet, als es schon FAT16B gab.

Wie gesagt, wir müssen unterscheiden, was das Dateisystem "an sich" hergibt, und was bestimmte Implementierungen konnten. Deine MS-DOS-Version wich während Deiner Tests offenbar nicht von 4KB-großen Clustern ab, aber das heißt nicht, daß Deine DOS-Version grundsätzlich keine größeren Cluster unterstützt - vielleicht würde sie es mit einer größeren Festplatte oder ein paar andere Blockgerätetreibern. Und selbst wenn es nicht so wäre, heißt es nicht, daß andere MS-DOS-OEM-Ausgaben nicht auch andere Werte verwenden konnten. Leider gab es damals bestimmt an die hundert verschiedene MS-DOS OEM-Anpassungen, die meist irgendwelche Obskuritäten aufwiesen. Insofern ist es immer gefährlich, von MS-DOS so zu sprechen, als hätte es nur eine generische Anpassung pro Versionsnummer gegeben - das war erst viel später so. -- 84.63.93.41 12:38, 25. Sep. 2009 (CEST)

• FAT32 hat auch so seine mysterien. Man kann mit FAT32 Cluster der Grösse 32768 Bytes (32kB) addressieren. Da 32 Bit kann man theoretisch 4294967296 Cluster Addressieren (2^32 ~= 4 Mrd) was zu 140737488355328 Bytes führen würde, was 131072GB bzw. 128 TB entspräche. Allerdings hat Microsoft von diesen Bytes 4 Stück reserviert, so dass nur 28 übrigbleiben, was zu den genannten 8TB führt. (Am rande sei noch bemerkt, dass man mit eingen tricks unter den NTs auch 64kB cluster hinbekommen kann, microsoft empfiehlt das aber nicht).

Es gibt eine inoffizielle FAT32-Erweiterung, die "FAT32B" genannt wird (auch im XBPB) und die die 32-Bit breiten FAT-Einträge voll ausnutzt, also auch die reservierten 4 Bit verwendet. Damit sind knapp 128 TB (mit 32 KB Clustern) bzw. knapp 256 TB (mit 64 KB Clustern) möglich. Diese wird in OEM DR-DOS 7.07 (und meines Wissens bisher nur dort) experimentell (neben dem "normalen" FAT32) implementiert. Booten kann man von solchen Volumes natürlich nicht, da MBR und Bootsektor bekanntlich nur 32-bit breite Einträge enthalten und man damit auf maximal 2 TB kommt. Mehr ginge nur mit EFI. Es ist jedoch möglich, solche Volumes über einen Blockgerätetreiber einzubinden, der dann die Abbildung nach unten auf das physikalische Medium (z.B. unter Beachtung von EFI) vornimmt. Allerdings ist FAT32B aufgrund der riesenhaften FAT nur sinnvoll für Volumes verwendbar, die überwiegend große Dateien enthalten und die in der Regel ohne viele Löschaktionen beschrieben werden und dann ggfs. ab und zu komplett neu formatiert werden, z.B. Archivsysteme oder Imageserver. Gegenüber exFAT hat das System immerhin den Vorteil, daß die Anpassungen am existierenden FAT32-Code minimal ausfallen und damit das Betriebssystem nicht aufblähen. -- 84.63.93.41 13:00, 25. Sep. 2009 (CEST)

Ich glaube wurden diese 4bit deshalb reserved, weil mit IDE/ATA ursprünglich nur mit 28bit Adressiert wurde, es daher sinnlos war, mahr als 2^28 Cluster zu addressieren. --MrBurns 18:28, 25. Sep. 2009 (CEST)

• eine Datei kann bei FAT32 ca. 4GB gross sein (die reale grenze liegt meist merkwüdigerweise knapp dadrunter, früher waren es sogar 2GB, meist sieht man in programmen "FAT32 extd." für die neue variante. Dies ist ansich auch eine willkürlich festgelegte grenze)

Soviel ich weiß schreibt FAT32 generell nur die 4GB-Grenze vor (bei FAT16 ist die Grenze natürlich 2GB, weil keine Datei kann größer sein als die Partition, auf der sie gespeichert ist). Wenn die Dateigröße auch bei FAT32 auf 2GB begrenzt ist, liegt das am OS, nicht am FAT. --MrBurns 18:36, 25. Sep. 2009 (CEST)

• ältere Windows versionen unterstützten maximal 32GB pro FAT32 partition, dies ist eine limitation der implementation, nicht des formates. selbst windows xp kann zwar mit grösseren partitionen umgehen, diese aber nicht selbst erstellen.

Diese Begrenzung gibts bei allen NT-Basierenden Windows-Versionen und generell nicht bei Win 95B/95C/98/98SE/Me. Alle diese Versionen können auch mit größeren FAT32-Partitionen umgehen, nur eben diese nicht mit den mitgelieferten tools selbst erstellen, man kann aber auf die Partitionen ganz normal zugreifen, wenn diese von einer third-Party-Software (z.B. fdisk von einer Windows 98/Me Startdiskette, das was im Fdisk-Artikel steht ist Schmarrn, man muß nur bei Partitionen ab diesen Größen die Größenangaben in % anstatt in MB angeben, ich habs selber mit einer 160GB-HDD ausprobiert). --MrBurns 18:36, 25. Sep. 2009 (CEST)

• die meist angegebene grenze von 2TB bezieht sich nicht auf das dateisystem, sonder auf die unterstützte maximale grösse von partitionen. unter windows xp z.b. kann man jedoch mehrere solcher partitionen logisch zu einem laufwerk zusammenfassen.

• Ein empfehlenswerter link ist [[1]] der windows XP behandelt und den aktuellen ersetzen sollte. Interessanterweise drückt sich microsoft selbst nicht so klar aus, gelegentlich wird von den 2TB als beschränkung von FAT32 gesprochen, was nicht richtig ist, es ist eine beschränkung der partitionsgrössen.

Die Beschränkung der Partitionsgröße auf 2TB gilt nur bei 512-Bytes-Sektoren. Es spricht ejdoch technsich nichts dagegen, die Sektoren bis zu 2048 Bytes groß werden zu lassen (siehe Master_Boot_Record), was glaub ich auch das Maximum ist, das unterstützt wird. Nur wurde das noch nicht gemacht, wiel ohnehin noch keine HDDs mit >2TB auf dem Markt sind. Aber es werden heute ohnehin kaum noch Clustergrößen unter 4kB verwendet, also sind Sektoren mit 2048 Bytes auch noch klein genug. --MrBurns 19:00, 25. Sep. 2009 (CEST)

So, und abschliessend finde ich den artikel "nicht hübsch", am layout könnte noch jemand der zeit hat, und kein legastheniker wie ich ist, auch etwas tun;) 84.176.181.199 17:54, 20. Okt 2005 (CEST)

FAT32

„habe zwar keine Ahnung, aber ich weiß, dass ich unter Win eine 300 GB-Platte mit einer 149 Gi“...
...B-FAT32-Partition betreibe, weshalb diese Aussage [gemeint: FAT32 ginge nur bis 32 GiB] nicht stimmt. -- Pemu 15:05, 23. Nov 2005 (CET)

Vielleicht variiert das ja zw. verschiedenen Windows-Versionen? Oder lässt sich - wie so oft - über einen registry-Eintrag einstellen? --RokerHRO 16:15, 23. Nov 2005 (CET)

Da war irgendwas beim Partitionieren. Aber „vielleicht“ ist vielleicht hier ok, mir aber zuwenig für den Artikel. -- Pemu 21:51, 23. Nov 2005 (CET)

„Die Partitionsgröße ist auf >32 TiB begrenzt.“ Aussage bedeutet, dass Partitionen mind. 32 TiB groß sein müssen. Ich habe FP mit FAT32-Partitionen, die kleiner sind. -- Pemu 15:02, 14. Dez 2005 (CET)

TiB

Was soll das mit TiB ? meinst Du(@Pemu) Terra Byte ? oder Terra Bit? der Verweis im Artikel auf Byte ist nicht gerade hilfreich. Für Terra gibt es verschiedene Auffassungen. In jeder Wissenschaft steht Terra im Allgemeinen für 1000^4, in der Informatik (ausser bei Grössenangaben von Herstellern von Festplatten :) ) für 1024^4. Bei der GiB Angabe im Text und der Anzahl der Bytes kann man auf 1024^3 Byte ist 0,9999 GiB. Irgentwie kommt mir da was nicht geheuer vor. Kann da mal jemand bitte Aufklären was es mit dem GiB und TiB auf sich hat und gegebenenfalls den Byte Artikel erweitern oder verständliche Angaben in bekannten Einheiten machen. Danke.Do ut des

Tebibyte. Siehe Binärpräfixe bzw. Speicherkapazität und Liste der Vorsilben für Maßeinheiten. 1000⁴ Byte heißen übrigens 1 Terabyte (ein r und kein Leerzeichen; SCNR, aber wenn es hier mehrfach falsch steht...) -- Pemu 16:22, 21. Jan 2006 (CET)

Die Abkürzungen GiB für Gigabyte, MiB für Megabyte ... sind mir nach 30 Jahren Berufspraxis als Informatiker hier zu ersten mal begegnet. In den technischen Spezifikationen für Dateisysteme wird man die nicht finden. Das Ganze ist also mal wieder so ein richtig akademischer Geisteswind.

-- Latimeria 14:00, 7. Apr. 2007 (CEST)

Würde ich auch meinen, ich kann mir darunter nichts vorstellen. Warum nicht eifach die gebräuchlichen Einheiten?

-- schneider.chr 13:37, 6. Mai. 2009 (CEST)

Technischer Hintergrund

„Partitionen kleiner als 512 MiB werden nach wie vor mit FAT16 erzeugt, dies hat aber keinen technischen Hintergrund.“ Ich vermute als technischen Hintergrund, dass die kleineren Partitionen auch noch mit älteren Systemen lesbar sein sollen.

Ich meine mich zu erinnern, im den FAT32-Spezifikationen gelesen zu haben, dass dort einfach festgeschrieben steht, dass kleinere Partitionen mit FAT16 formatiert sein müssen, dass also die FAT32-Spezifikation eine Mindestgröße verlangen.

Wenn mit dem Satz oben gemeint ist, dass diese Mindestgröße ohne technische Zwänge, die sich aus den FAT32-Spezifikationen ergeben, quasi vom Himmel gefallen ist, so würde ich das auch so hinschreiben.

-- Pemu 20:35, 8. Jan 2006 (CET)

Andere Programme (wie Partition Magic) können kleiner Partitionen mit FAT32 erstellen, diese funktionieren auch unter WinDOS, also eine reine "politische" Entscheidung von Microsoft.

Windows ME wird unter Windows 9x subsummiert (siehe auch dort) ;-)

--WikiMax 21:10, 8. Jan 2006 (CET)

--

Hi - die verbreitete Meinung, Partitionen < 512 MB koennten nicht mit FAT32 formatiert werden, ist Quatsch. Selbst der M$-DOS Format-Befehl kennt den undokumentierten Parameter /z:x

Der steht fuer (Groesse der) Zuordnungseinheit. x repraesentiert ein Byte.

Jeweils ein Bit dieses Byte kann gesetzt werden durch Angabe des entsprechenden Dezimalwertes. Zwischenwerte werden mit Fehlermeldung "ungueltiger Wert" zurueckgewiesen. x kann gueltige Werte zwischen 1 und 128 annehmen.

Das gesetzte Bit steht fuer die gewuenschte Groesse der Zuordnungseinheit. 1x2^0 (dez. 1) steht dabei fuer 512 Byte, 1x2^1 (dez. 2) fuer 1 KiloByte, 1x2^2 (dez. 4) fuer 2 KB, 1x2^3 (dez. 8) fuer 4 KB, ... usw. ... bis 1x2^7 (dez. 128) fuer 64 KB.

Entgegen der weit verbreiteten Meinung sind so auch Partitionen kleiner 512 MB mit FAT32 moeglich. Mittels vorgenannten Parameters muß die Blockgroesse dabei lediglich z.B. auf 0,5 KB (512 Byte) gesetzt werden.

Tatsaechliche allgem. moegliche Groessen der Zuordnungseinheiten fuer FAT32 sind:
Partitionsgroesse	zul. Blockgroesse	sinnvolle Blockgroesse	M$-Empfehlung
32 MB bis 512 MB	0,5 KB bis 64 KB	0,5 KB bis 2 KB	nicht gewuenscht, deshalb undokumentiert
512 MB bis 2 GB	0,5 KB bis 64 KB	2 KB bis 4 KB	4 KB
2 GB bis 8 GB	4 KB bis 64 KB	8 KB	4 KB
8 GB bis 32 GB	4 KB bis 64 KB	16 KB	8 KB bis 16 KB
> 32 GB	4 KB bis 64 KB	16 KB bis 64 KB (*)	32 KB
(*) je nach Partitionsgroesse und Verwendungszweck / gespeicherte Dateitypen

in XP (und aequivalent 2K, 2K3, NT4.x ?) sind an verschiedenen Punkten die Formatierungs-Moeglichkeiten kuenstlich (vorsaetzlich) beschraenkt und / oder erschwert, um unerfahrene User zu Verunsichern / im Ungewissen zu lassen und zwangsweise den Umstieg auf das streng proprietaere, nicht fuer andere Betriebssysteme zur Nutzung freigegebene NTFS zu erzwingen. Grundsaetzlich laesst sich FAT32 aber vollwertig unter den gen. Systemen verwenden; ggf. mit ein wenig gutem Willen und etwas 'Nachhilfe' ... ;-)

unter XP z.B. sind oben angefuehrte Formatierungen und Blockgroessen manuell in der Datentraegerverwaltung einstellbar ... :D

cu  :)  m,- 

--

FAT16 bis 4GB

Der Absatz zu FAT16 sollte überarbeitet werden, denn laut der Microsoft Knowledge Base, Artikel 310561

Maximale Partitionsgröße bei Verwendung des FAT16-Dateisystems in Windows XP

unterstützt Windows XP das Erstellen primärer Partitionen und logischer Laufwerke einer Größe von bis zu 4 Gigabyte (GB) mit dem FAT16-Dateisystem.

Gruß Michael

Das habe ich GESTERN(!) doch schon gemacht: "Windows NT kann allerdings 4 GiB große FAT16-Partitionen erzeugen und verwalten. (Clustergröße 64 KiB)" *kopfschüttel*. Oder liegt es daran, dass du nicht weißt, dass Windows XP die Version Windows NT 5.1 ist? Dann hat mein Einschub den Oma-Test nicht bestanden. --WikiMax 16:50, 9. Jan 2006 (CET)

MiB vs MB

Kleiner Vorschlag, auch wenn die Umsetzung zu _deutlicher_ Redundanz führen würde. Da sich gerade wieder gezeigt hat dass UNterschied zwischen MB und MiB (stellvertretend als Beispiel) nicht klar ist und MiB vermutlich in jedem Oma-Test versagen würde (die eine oder andere Oma würde vielleicht noch MB verstehen, aber nicht MiB). Auf Seiten wo es zu Problemen (für omA) führen würde, ganz kurze MiB/MB-Erklärung einfügen. Wie gesagt, es geht primär um omA, wer FAT sucht, hat eben wenig Fachwissen in diesem Bereich. --WikiMax 20:06, 22. Jan 2006 (CET)

Vielleicht wäre in Artikeln wie diesem eine Art "Spoiler"-Textbaustein nicht verkehrt. Etwa: "Dieser Artikel verwendet binäre Einheitenpräfixe. [...]" usw. ähnlich wie es das für Unicode und mathematische Formeln gibt. Was haltet ihr davon? --RokerHRO 21:12, 22. Jan 2006 (CET)

Garnichts. Besser waere es, wenn jede erste Nennung von "MiB" oder "TiB" auf den Artikel mit den Binaerpraefixen verweisen wuerde. So kann jemand, der das nicht kennt, einfach draufklicken, waehrend die, die das schon kennen, nicht mit unnoetigen Informationen zugemuellt wird. 130.83.244.129 18:33, 26. Jan 2006 (CET)

Stimmt. Leider habe ich in unzähligen Artikeln immer wieder fälschlich von MiB nach MB korrigierte Artikel reverten müssen. Dass bei der jeweils ersten Verwendung MiB und KiB verlinkt war, hat nicht geholfen. Selbst ein <!-- sic --> hielt diverse Benutzer (nicht nur IPs) nicht von einem Edit ab. :-( --RokerHRO 21:34, 26. Jan 2006 (CET)

Endlich mal ein Artikel der korrekter Weise die Binärpräfixe verwendet, leider tun das nur sehr wenige, aus Unwissenheit, oder weil sie es von den Diversen OSsen falsch gewöhnt sind. Daher würde ich auch empfehlen so eine Art "Spoiler"-Textbaustein einzufügen, und jeden Binärpräfixe auf die entsprechende Seite#Anker zu verweisen, damit die Gefahr kleiner wird, das jemand sie zu SI-Präfixe falsch-korrigiert. Kirsch ger 15:33, 27. Okt. 2007 (CEST)

Dafür hatte ich mal eine Vorlage gebastelt, welche aber nach kontroverser Diskussion von Benutzer:Markus Mueller gelöscht wurde. Siehe Wikipedia:Löschkandidaten/12._Februar_2006. :-( --RokerHRO 20:26, 27. Okt. 2007 (CEST)

Fehler in der FAT

Vielleicht könnte jemand etwas zu "verlorene Dateifragmente", "querverbundene Dateien" und "ungültige Dateinamen" schreiben? Das sind doch alles Fehler in der FAT, oder? --Zahnstein 20:22, 27. Mär 2006 (CEST)

Stimmt. Querverbundene Dateien kenne ich nicht, nur "kreuzverbundene Dateien". Das sind Dateien, die sich ganz oder teilweise eine Clusterkette teilen. Sowas ist in FAT nicht erlaubt. "Ungültige Dateinamen" entstehen in der Regel, wenn dort, wo Verzeichniseinträge stehen sollten, andere Daten geschrieben worden sind, damit sind eigentlich die gesamten Verzeichniseinträge ungültig, aber am ungültigen Dateinamen wird sowas am auffälligsten. "Verlorene Dateifragmente" sagt mir nichts. Vielleicht ist damit gemeint, wenn die Clusterkette auf freie Cluster verweist oder kürzer ist, als die im Verzeichniseintrag angegebene Dateilänge? --RokerHRO 11:33, 30. Jul 2006 (CEST)

Dateinamenskonventionen

hier fehlt ein wenig Info.

z.B. daß sämtliche auf FAT basierenden Filesysteme Case-Insensitiv sind, d.h. daß nicht zwischen Groß- und Kleinschreibung unterschieden wird

Es ist die Frage, ob das eine Eigenschaft des FAT-Dateisystems ist, oder des Dateisystemtreibers im Betriebssystem. Bei 8.3-Namen sind halt nur ASCII-Großbuchstaben, Ziffern und eine Handvoll Sonderzeichen zulässig. Was aber mit nicht-ASCII-Buchstaben ist, oder was passiert, wenn Kleinbuchstaben im Dateinamen stehen, ist IMHO nicht geklärt.

Ein Indiz dafür, dass es der DOS-/Windows-Treiber ist, der bei Dateinamen zw. Groß-/Kleinschreibung verwischt, ist die Tatsache, dass Windows auch bei "langen Dateinamen", NTFS und Netwerkvolumes nicht zwischen Groß- und Kleinschreibung unterscheidet, obwohl diese Systeme durchaus auch Kleinbuchstaben zulassen. --RokerHRO 07:48, 5. Jan. 2007 (CET)

Noch ein Indiz ist, dass, wenn man Linux falsch konfiguriert, damit auch zwei Dateien erzeugen kann, deren Namen sich nur durch Groß-/Kleinschreibung unterscheiden.

Aber: Natürlich steht ja irgendwo, dass der Treiber nicht zwischen Groß- und Kleinschreibung unterscheiden soll. Das steht halt in der Spezifikation des Dateisystems. Daher gehört es mMn ganz klar hier rein.

Hier wird auch ein sprachliches Problem deutlich: Das Wort Dateisystem kenne ich in unterschiedlichen Bedeutungen:

• Als Dateisystemstruktur auf dem Datenträger – sie kann natürlich nicht zwischen Groß- und Kleinschreibung unterschieden;
• als Dateisystemhandler bzw. -treiber, der unterscheiden kann oder auch nicht – hier aber wohl nicht unterscheiden darf bzw. sollte.

-- Pemu 19:23, 7. Jan. 2007 (CET)

FATX

Hab heute in der Nachricht NetBSD für die Xbox von Pro-Linux gelesen, dass die alte Microsoft XBox FATX nutzt. Ist das eine Erweiterung von FAT32? Vielleicht könnte FATX mit in den Artikel aufgenommen werden. -- Haeber (Disk., Bew.); 12:56, 10. Jan. 2007 (CET)

Wer hats erfunden?

In der englischen Version steht die FAT wurde von Microsoft entwickelt. Ich vermute das stimmt auch, weiß es aber nicht genau. 129.143.15.174 19:34, 31. Jan. 2007 (CET)

Es wurde auch von MS entwickelt. Schon Microsofts Disk-BASIC-Interpreter der späten 70er Jahre verwendeten FAT und Tim Paterson hat es bei der Entwicklung von QDOS übernommen. --Ruscsi 02:17, 11. Sep. 2007 (CEST)

Artikel

Heißt es nicht eher "die FAT", wie "die Tabelle"? -- Polluks ★ 12:10, 30. Apr. 2007 (CEST)

MiB, GiB und TiB

wofür steht, dass i, müsste es nicht MB, Gb, und TB lauten?

Gut dass du fragst und nicht einfach den vermeintlichen Tippfehler "korrigierst". Die meisten der Einheitenabkürzungen sind übrigens verlinkt, entweder zu Byte oder zu Binärpräfixe. In beiden Artikeln ist der Sachverhalt erklärt. --RokerHRO 19:16, 17. Mai 2007 (CEST)

Beispiel DOS- bzw. Windows-Diskette mit FAT12 File Allocation Table

(Auszug aus dem beanstandeten Absatz:)

Die ersten drei Bytes im FAT F0hFFhFFh sehen binär geschrieben so aus (Erklärung der 'bit order' siehe weiter unten):

00001111 11111111 11111111 – die ersten 12 Bit sind also: 000011111111 – diese repräsentieren den Wert FF0h, die nächsten 12 stehen für FFFh. Das bedeutet, beide Cluster sind reserviert 4600h–49FFh […] Dritter und vierter Datencluster der Diskette. Die normale Bitreihenfolge (bit order) ist das 'up bit ordering', das 'least significant bit' steht zuerst (Daneben gibt es das 'down bit ordering', auch 'reverse bit direction' – man spricht hier von 'bit sex', analog bei Bytes von der Endianness).

Auf der Diskette sind die drei den beiden Sektore entsprechenden FAT-Bytes 32hD0h47h folgendermaßen repräsentiert: 00100011 00001101 01110100 – die ersten 12 Bit: 001000110000 bedeuten 032h=50, die nächsten 12 Bits 110101110100 stehen für 47Dh=1149. Man muss demnach die Bits in Vierergruppen von hinten nach vorn lesen, um die entsprechenden Hexadezimalzahlen zu erhalten, da bei unserer Schreibung die 'most significant' Ziffer links, also zuerst steht. Die Bedeutung der Zahlen 47 und 1149: Auf den 3. Cluster, der Teil einer Datei ist, möglicherweise auch deren Anfang, folgt der 47. Datencluster als nächster Teil dieser Datei. Der 4. Cluster, der auch zu derselben Datei (an anderer Stelle) gehören könnte, vielleicht aber auch zu einer ganz anderen, hat als Nachfolger den Cluster 1149. Zu jedem Datencluster ist also sein Nachfolger im FAT vermerkt, beim letzten Cluster eines Files steht im FAT ein FFFh

---

Obiger Bereich aus dem Absatz Beispiel DOS- bzw. Windows-Diskette mit FAT12 File Allocation Table sollte überarbeitet werden!

1. Werte, die mehr als ein Byte benötigen werden zwar im "Intel-Format" abgelegt, d.h. das niederwertigste Byte zuerst (insofern also von hinten nach vorn zu lesen, aber eben byteweise und nicht bit- oder nibbleweise!)

F0hFFhFFh sieht daher binär im Speicher so aus 11110000 11111111 11111111
desgleichen wird
32hD0h47h im Speicher binär als 00110010 11010000 01000111 abgelegt!
Zur Interpretation der (hier letzteren) 3 Byte schreibe man sie in umgekehrter Reihenfolge auf, also das höchstwertige Byte zuerst:
(Das dient rein der Anschauung des Menschen, der i.d.R. gewohnt ist, Ziffern einer Zahl mit höherer Stellenwertigkeit links anzuordnen.)

01000111 11010000 00110010

   4_h    7_h    D_h    0_h    3_h    2_h

Die rechten 12 bit repräsentieren hier Datencluster 3 (032h=50, mit der Bedeutung, dass der Nachfolgecluster zu diesem Cluster 3 der Cluster 50 ist) Die linken 12 bit repräsentieren hier Datencluster 4 (47Dh=1149, mit der Bedeutung, dass der Nachfolgecluster zu diesem Cluster 4 der Cluster 1149 ist)

2. auf einen 47. Datencluster wird hier an keiner Stelle verwiesen . . .

--84.131.145.88 05:37, 3. Jul. 2007 Signatur nachgetragen, Rat 22:52, 4. Jul. 2007 (CEST)

Die Byte-Verdreherei ist falsch erklärt aber im Ergebnis richtig. Allerdings ist das Beispiel ziemlich unglücklich gewählt. Falsch ist, dass die beiden dem Stammverzeichnis folgenden Cluster reserviert seien (warum sollten sie?). Die ersten beiden Einträge FAT[0] und FAT[1] sind zwei 2 Pseudoeinträge, die Nummerierung der Datencluster (nach dem RootDir) beginnt mit 2.

Das Beispiel halte ich deshalb für unglücklich, weil (zumindest bei frischen Disketten) die Cluster in der Reihenfolge beschrieben werden, will heißen, der jeweils nächste freie Cluster wird benutzt. Dadurch erhält man in der FAT verkettete Listen von aufsteigenden Clusternummern und üblicherweise keine Rückwärtssprünge. Ich bezweifle, dass das Beispiel aus dem richtigen Leben stammt. Ich habe mal eine frisch formatierte Diskette mit 2 Dateien beschrieben. Die erste Datei belegt 2050 Bytes (5 Cluster 002-006), die zweite Datei ist länger (Cluster 007 - ...). Im Directory finde ich als Startcluster die Nummern 0002 und 0007. In der Fat finde ich die folgende Bytefolge:

F0 FF FF 03  40 00 05 60  00 FF 8F 00  09 A0 00 0B
C0 00 0D E0  00 0F 00 01  11 20 01 13  40 01 15 60

Aus jeweils drei Bytes ab cd ef werden 2 12-Bit Zahlen dab efc, d.h. vom mittleren Byte wird das rechte Halbbyte vor das erste Byte gestellt und das linke Halbbyte hinter das dritte Byte. Microsoft drückt das hier so aus: "We now access the FAT entry as a WORD just as we do for FAT16, but if the cluster number is EVEN, we only want the low 12-bits of the 16-bits we fetch; and if the cluster number is ODD, we only want the high 12-bits of the 16-bits we fetch." Damit entspricht obiges Beispiel folgender Verzeigerung:

FF0 FFF 003 004 005 006 FFF 008 009 00A 00B
00C 00D 00E 00F 010 011 012 013 014 015 ..6

Ich habe allerdings Bedenken, ob das nicht den Rahmen eines üblichen Enzyklopädieeintrages sprengen würde. --Rat 22:52, 4. Jul. 2007 (CEST)

Danke für die Überarbeitung - schon viel besser! ;-) --Parasoft 22:17, 6. Jul. 2007 (CEST)

FAT ist deutlich älter als QDOS

Tim Patterson hat das Dateisystem übernommen, da es von dem BASIC-Dialekt, den MS auf den SCP-Rechner portiert hat eh bereits als Speicherformat verwendet wurde. Laut MS stammt es ursprünglich sogar von einem Betriebssystem namens MDOS, das MS nie veröffentlicht hat. Quelle: MS-DOS-Encyclopedia. --Ruscsi 19:54, 17. Jan. 2008 (CET)

Es gibt in der Tat Hinweise auf einen Basic-Interpreter, der als "Standalone-Version", also ohne zugehöriges Betriebssystem, für den NCR-Rechner (was auch immer das für einer ist) entwickelt wurde. Der Hinweis findet sich im Artikel MS-DOS#PC-DOS 1.0.2C MS-DOS 1.x (und mehr dazu hier: http://209.85.135.104/search?q=cache:Yyion_oo1d8J:www.ugrad.cs.jhu.edu/~cs318/fat32.ps+Disk-BASIC-Interpreter+fat&hl=de&ct=clnk&cd=6&gl=de). -- Qhx 14:46, 2. Aug. 2008 (CEST)

Vergleichende Übersichtstabelle

Ich fände es schön, wenn am Anfang der Versionen eine Übersicht wäre in der Art:

!  !!  !! Maximalwerte für

Fat (Datencluster)	Clustergröße	Dateigröße	Partitionsgröße
FAT12 (4086)	512 B	2 MiB	2 MiB
bis zu	4096 B	2 MiB	16 MiB
FAT16 (65.526)	512 B	2 GiB	32 MiB
(max unter DOS)	32 KiB	2 GiB	2 GiB
bis zu	64 KiB	4 GiB	4 GiB
FAT32 (268.435.445)	512 B	4 GiB	32 GiB
	4 KiB	4 GiB	32 GiB
von Win max erstellbar	16 KiB	4 GiB	32 GiB
bis zu	32 KiB	4 GiB	8 TiB

! Bei den Clustergrößen gibt es alle Zwischenstufen, die sich durch Verdoppelung einer Clustergröße ergeben. ! Die Sektorgröße wird als 512 Bytes angenommen und so auch überall benutzt. Sie kann auch auf 1.024, 2.048 oder 4.096 Bytes gesetzt werden, was eine Verachtfachung der Größenangaben bewirkt aber nicht immer funktionieren dürfte.

Die DatenClusterAnzahl ergibt sich aus den Bits pro Cluster der FAT bis auf die letzten 9 abzüglich 0 und 1 und bei FAT32 dem Hauptverzeichnis (das ich mal mit einem Cluster ansetze) zuzüglich des letzten Clusters. (Oder zählen die FATs bei den Clustern mit? Wofür wird Cluster 1 abgezogen (hatte ich aus der ClusterTabelle im Artikel bei der ich mal die '<' als '<=' interpretiere)?)

Werte hier zusammengesucht oder gerechnet, deshalb zu prüfen! Lutz 16:39, 25. Jan. 2008 (CET)

FAT32plus?

Was ist FAT32plus? Die angegebenen Links führen zu keinen Informationen. Und die einzigen Seiten, die man findet, wenn man bei Google nach FAT32plus sucht, ist Wikipedia und einige Klone.--Sixot 17:18, 14. Mär. 2008 (CET)

Mit "FAT32plus" ist wahrscheinlich die (öfter genutzte und bekanntere) Variante von FATplus gemeint, nämlich die, die ein FAT32-Dateisystem erweitert. (Anstatt einem FAT16-Dateisystem, was nur mit einer Clustergröße ab 128 KiB möglich ist.) Informationen beispielsweise im Club Dr-DOS Wiki: Main / FAT+. Unten ist dort der Link zur aktuellen Spezifikation (Entwurf, 2. Revision) gegeben. --Estron 11:18, 30. Mär. 2008 (CEST)

Grenzen

"Mittlerweile wird NTFS auch unter Linux unterstützt, sodass die Verwendung von FAT32 aufgrund seiner Begrenzung auf 4 GB große Dateien eher nachteilig ist. Diese Grenze ist jedoch nur durch den Formatierungsassistenten von Windows gesetzt und kann umgangen werden."

Das stimmt nicht ganz. Eine Grenze des Formatierungsassistenten von Windows ist die maximale Partitionsgröße von 32 GB für FAT32. Aber die 4 GB Dateigröße gilt generell für FAT32 und kann nicht umgangen werden. Ich streiche daher den zweiten Satz jetzt! --195.227.10.67 16:21, 14. Apr. 2008 (CEST)

Was sich in der Tat umgehen lässt, ist die 32 GB-Grenze für Fat32, die keines der Fremdprogramme (wie z.B. Partition Magic) kennt. Auch mit gängigen Imageprogrammen lässt sich eine gesicherte Fat32-Partition beim Rücksichern in (fast) jeder beliebigen Größe anpassen. Ich habe dies ein paar Mal genutzt, als ich unter NT 4.0 (mit Fat32-Treiber) gearbeitet habe und die Partitionen zu Win98 kompatibel halten wollte.
Übrigens (und weil's aus obiger Tabelle nicht explizit hervorgeht): NT 4.0 war bei Fat16 auch nicht auf 2 GB beschränkt, sondern konnte (als einziges M$-Betriebssystem) solche Partitionen bis 4 GB anlegen. Und weil es das Einzige Betriebssystem war, war dies als Kompatibilitätsoption einzig und allein zum installieren sinnvoll, weil NTFS bei diesem Betriebssystem trotz einer entsprechenden Installationsoption noch gar nicht angelegt werden konnte, sondern immer erst beim Neustart aus Fat konvertiert wurde. --Qhx 08:59, 3. Mai 2008 (CEST)

MiB --> MB

Binärpräfixe wurden entfernt, aber dann wieder revertiert.

Die IP hat sich wahrscheinlich auf WP:Meinungsbilder/Benennung_von_Datenmengen bezogen. Die Verwendung von Binärpräfixen in der WP wurde dort mit großer Mehrheit als Theoriefindung/Begriffsetablierung abgelehnt. -- 88.72.133.149 11:21, 6. Jun. 2008 (CEST)

Wie bei der Diskussion dieses Meinungsbildes bereits kritisiert, ist die Zulässigkeit einer Meinungsbildes zu diesem Thema mehr als fragwürdig. Das ist etwa so, als würdest Du über den Durchmesser des Erde abstimmen oder über den Wert der Zahl Pi. Die Verwendung der SI-Präfixe in diesem Zusammenhang ist schlicht und einfach falsch und Du kannst von niemandem hier verlangen, dass er das befürwortet oder hier verwendet. Die Kommentare der Befürworten zeigen zudem überdeutlich, dass die Problematik von vielen nichtmal im Ansatz verstanden wurde. Auch die SI-Präfixe konnten sich erst durchsetzen, nachdem die Kultusministerien deren Verwendung im Physik-Unterricht in den 70ern verbindlich vorgeschrieben haben. --Ruscsi 13:35, 6. Jun. 2008 (CEST)

Deine Meinung; die Mehrheit hat aus guten Gründen anders entschieden. Das Thema wurde ausführlich diskutiert, und die Argumente, die du hier vorbringst, konnten nicht überzeugen. Ich sehe nicht, warum das Meinungsbild gerade für diesen Artikel irrelevant sein sollte. --84.179.196.120 00:10, 7. Jun. 2008 (CEST)

Das ist keine Sache, wo man eine Meinung zu haben könnte. Die Verwendung der SI-Präfixe als Binärpräfixe ist schlicht und einfach falsch! Ich verstehe nicht, was es da zu diskutieren geben sollte? --Ruscsi 12:58, 7. Jun. 2008 (CEST)

Wenn du es nicht verstehst, nachdem du die Diskussion zu besagtem Meinungsbild gelesen hast, kannst du dort nachfragen oder die Sachdiskussion an geeigneter Stelle wieder aufnehmen. [Portal:Informatik] dürfte der geeignete Ort sein, es betrifft ja nicht nur diesen Artikel. Solange nichts anderes entschieden wird, gilt [[2]] jedenfalls auch für diesen Artikel, und das ist gut so. Den "korrekten" weltfremden Kibibikindergarten konnte man ja nicht mehr mit ansehen. --84.179.196.120 15:50, 7. Jun. 2008 (CEST)

Aha. Daher weht der Wind. Es geht Dir also tatsächlich nicht um Sachargumente, sondern darum, dass die korrekte Darstellung für Dich ein Kindergarten ist. Bezeichnend ist auch, dass Du offensichtlich bei WP zwar sehr engangiert bist, aber zu feige bist, Dich bei solchen Sprüchen nicht hinter einer IP zu verbregen. Schöne neue Wikipedia. Zu Deiner Info: Ich kenne die Sach"argumente", die angeblich dafür sprechen sollen. Sie sind inkonsequent, mathematisch inkorrekt, selbst bei Akzeptanz einiger Grundannahmen nicht durchgehend korrekt darstellbar und sogar widersprüchlich. Darüber können keine Krücken hinweghelfen. Was mich aber viel mehr wundert: Darüber, was korrekt ist, kann ab jetzt bei WP also einfach abgestimmt werden. Bin mal gespannt, wann hier darüber abgestimmt wird, wie sich historische Ereignisse zugetragen haben. Arme Wikipedia. Nichtsdestotrotz: Die Sache mit den Fussnoten ist schonmal besser als die kommentarlose Falschdarstellung. --Ruscsi 23:18, 7. Jun. 2008 (CEST)

Vielleicht siehst du die Sachargumente als solche nicht ein. Falsch ist die Darstellung eben nur in den Augen einiger Binärpräfix-Befürworter, die meinen, hier in der Wikipedia das erreichen zu müssen, was im Rest der Welt nicht erreicht wurde, nämlich die Konvention "kilo bei Datenmengen = 1024" abzuschaffen und durch etwas neues zu ersetzen. Der im MB befürwortete Vorschlag dagegen geht sogar einen Schritt weiter und verlangt die binäre Darstellung auch bei Festplatten, was der Eindeutigkeit wiederum zuträglich ist. Die Leute dort haben sehr wohl verstanden, worüber sie abstimmen. Das mit den Fußnoten kann man machen, ist zwar eigentlich unnötig, aber es richtet keinen Schaden an. Aber das wurde wie gesagt beim MB schon ausführlich durchgekaut, und es hat keinen Sinn, die Diskussion hier für diesen Artikel neu aufzurollen, zumal offenbar niemand neue Argumente hat. Es würde wahrscheinlich das gleiche herauskommen, und es wird immer Leute geben, denen das Ergebnis nicht passt, und die dann entsprechend schäumen und von Falschdarstellung o.ä. sprechen. Da muß man drüberstehen. --84.179.204.150 00:13, 9. Jun. 2008 (CEST)

Die Schose ist doch ganz einfach: Das IEC hat ausdrücklich festgelegt, dass die Dezimalpräfixe ausschließlich dezimal, also mit dem Faktor 1000, verwendet werden dürfen. Im gleichen Zuge hat es festgelegt, dass für den Faktor 1024 die Binärpräfixe zu verwenden sind. Da gibt es gar nichts zu diskutieren.--Sixot 14:35, 3. Aug. 2008 (CEST)

an sich nicht, aber da sich ja das Wikipedia-Projekt auf Quellen stützen will/sollte/muss, kommt die von der IEC generierte Doppeldeutigkeit zum Tragen: Du wirst in keinem alten Buch zu DOS, FAT und anderem Grössenangaben in MiB finden, sondern nur in MB. Ich finde alleine deswegen ist eine Erklärung nicht nur sinnvoll, sondern notwendig. --Andy386 19:43, 21. Jan. 2009 (CEST)

FAT 12 mit 32 MB und Hinweis auf "FAT 8"

In der en-Wikipedia sind 32 MB als Grenze für FAT 12 angegeben, es gibt auch weitere Hinweiese und Links, u.a. hier:

• http://www.wer-weiss-was.de/theme30/article3626896.html (32 MB als halbproprietäre FAT 12-Erweiterung für Flash-Speicher)
• Handbuch zum "Partition Star" (Star-Tools GmbH, © 1997-2000), S. 9 (Partitionstypen); Eintrag: FAT 12, Partition kleiner als 32 MB und Ende unterhalb von 8 GB: Typ "01"

Weiß jemand was darüber? Scheint, dass die Spezifikation 32 MB-Partitionen zulässt, implementiert wurden in DOS und Linux jedoch nur Formatierungsfunktionen bis 16 MB. Sehe ich das richtig so? Oder hat es damit was zu tun, dass auf Disketten und Flashspeicher nur eine Partition verwendet wird und somit ohne Partitionstabelle auch der erste Cluster für Dateien zur Verfügung steht?

Außerdem gibt es im Internet Hinweise auf ein FAT 8, das zumindest bis zu einer gültigen Spezifikation entwickelt sein muss, Hinweise finden sich z.B. hier:

• http://www.vbforums.com/archive/index.php/t-40818.html

Weitere Beiträge (z.B. aus Foren) finden sich unter Nickles, dcresource.com (Hier behauptet jemand sogar, es könne bis zu 512 MB verwalten, in seiner Aufzählung fehlt allerdings FAT 12), Chip (ein Autoradio könne nur FAT 8 und 16 lesen) ... Falls das stimmt, könnte man das zumindest erwähnen, weil es ja dann vermutlich eine Alpha- oder Beta-Version von FAT 12 ist und somit ebenfalls relevant ist, ebenso wie Windows 1.x auch nur als Vorläufer des Quasi-Monopolisten relevant ist. -- Qhx 14:38, 2. Aug. 2008 (CEST)

kennt exFAT Dateiendungen mit mehr als 3 Buchstaben?

Ein Nachteil alter FAT-Systeme ist für mich, dass sich Dateien mit Endungen wie .docx oder .flac in .doc und .fla umwandeln, wenn sie über einen FAT-Speicher von einem Computer zu einem anderen transportiert werden. Es gibt noch viele andere Suffixe, die teilweise aus fünf Zeichen bestehen. Wurde das Problem mit exFAT behoben? --SvenEric 11:26, 11. Sep. 2008 (CEST)

Ich kann Dir die Frage nicht genau beantworten, aber ich bin mir einigermaßen sicher, dass das kein Problem des Dateisystems ist, sondern der M$-Treiber. In den 80er Jahren habe ich eine Samsung-Schreibmaschine mit Diskettenlaufwerk gekauft. Die war zwar so langsam, dass ich sie gleich wieder umgetauscht habe (gegen eine Brother), aber bei der Namensgebung der Dateien auf Fat12-Diskette war sie sehr flexibel. Es mussten lediglich max. 12 Zeichen sein, wo der Punkt stand (und ob überhaupt einer benutzt wurde), war egal. (Ob es der M$-DOS-Treiber hätte lesen können, kann ich nicht beurteilen, aber das Disketten-Dateisystem Fat12 ist definitiv kompatibel.) Die Brother hingegen prüfte auf die Einhaltung korrekter DOS-Konventionen (mit WPT-Dateiendung). Und da Fat16 eine Weiterentwicklung vom Diskettensystem Fat12 ist, denke ich, dass der Punkt theoretisch an jeder beliebiger Stelle stehen könnte, wenn es der Treiber zulassen würde. Nur die Gesamtzahl von 12 Zeichen ist halt eine Spezifikation des alten Fat-Dateisystems, weil Speicherplatzoptimierung damals oberste Priorität hatte. -- Qhx 18:49, 11. Sep. 2008 (CEST)

Och Leute, das steht doch alles schon im Artikel: FAT (egal ob 12,16 oder 32 bit) speichert pro Verzeichniseintrag nur einen 8.3-Namen, wobei der Punkt nicht mitgespeichert wird. Für alle 3 FAT-Varianten gibts mit "Long File Names" (LFN, aber üblicherweise irreführend als "VFAT" bezeichnet) eine Erweiterung, die von MS mit Win95 eingeführt wurde, die mehrere Verzeichniseinträge benutzt, um lange Dateinamen (und dazu noch in Unicode) zu speichern. Andere Betriebssystem-Treiber haben/hatten ihre eigenen, untereinander und zu LFN inkompatible FAT-Erweiterungen, um lange Dateinamen zu speichern, etwa OS/2, WinNT 3.5, PC GEOS, Mac OS 7, UMSDOS, usw. --RokerHRO 20:32, 11. Sep. 2008 (CEST)

@RokerHRO: Unicode!?!? Bist Du sicher? Ich habe einige polnische Programme auf meinem Fileserver, da werden die im Dateinamen enthaltenen polnischen Sonderzeichen im deutschen Windows NICHT richtig dargestellt (betrifft Fat32 und Ntfs). Und wenn ich mich richtig erinnere, ist es umgekehrt (dt. Software unter PL-Windows) genauso. -- Qhx 08:34, 15. Jan. 2009 (CET)

Ja, ich bin mir sicher. Steht doch alles im Artikel und auch so in der Spec von Microsoft. Wenn du die Dateien auf einem Fileserver hast, greifst du ja übers Netzwerk darauf zu, oder? Als benutzt du dafür Protokolle wie SMB/CIFS/NFS usw. Da werden nicht-ASCII-Dateinamen anders behandelt als bei FAT mit "Long Filenames". Zum Teil kann man da Dateinamen auch von einem Zeichensatz in einen anderen konvertieren, das hängt davon ab, was der Fileserver kann und wie er eingerichtet ist. Mit FAT hat das aber alles nichts zu tun. --RokerHRO 13:47, 15. Jan. 2009 (CET)

Problem mit der Fragmentierung?

Da FAT doch ziemlich schnell fragmentiert gerade auch im Vergleich zu NTFS sollte vielleicht auch erwähnt werden. Vielleicht könnte ja auch die generelle Problematik Fragmentierung mit rein.

Fenris81 15:37, 13. Jan. 2009 (CET)

Hast du denn auch zitierfähige Quellen/Belege für deine Aussage? :-) Nur weil die derzeitien FAT-Implementierungen sich wenig darum scheren, die Fragmentierung kleinzuhalten, ist das nicht zwangsläufig eine designte Eigenschaft des Dateisystems. --RokerHRO 17:06, 13. Jan. 2009 (CET)

Naja, ich habe halt die Erfahrung mit meinem Windoes-System gemacht, dass FAT sehr sehr schnell fragmentiert gegenüber NTFS. Aber ich habe das nochmal nachgegoogelt. Und es scheint tatsächlich so zu sein, dass der FAT-Treiber unter Windows an der starken Fragmentierung schuld ist.

http://forum.ubuntuusers.de/topic/fragmentiert-linux-fat-partitionen/?highlight=mp3#post-874257

Fenris81 13:59, 14. Jan. 2009 (CET)

Tja, dann hast du für dich ja eine Antwort. Leider sind Webforen ungeeignet als Referenz, siehe WP:WEB. --RokerHRO 21:50, 14. Jan. 2009 (CET)

FAT 32 läuft auch unter MS-DOS 7.10 und 8.0 (enthalten in Windows 95b/95c/98 bzw. Me)

Ich hab diese DOS-Versionen also bei den unterstützen hinzugefügt. --MrBurns 05:46, 20. Feb. 2009 (CET)

Patent

Habe folgenden Abschnitt entfernt:

Nach langen Rechtsstreitigkeiten und einem zweijährigen Patentierungsverfahren wurde am 10. Januar 2006 das Patent und die damit verbundene enorme Marktmacht für FAT (FAT12, -16, -32 etc.) der Herstellerfirma Microsoft zugesprochen. Das deutsche Bundespatentgericht erklärte eines der beiden diesen Schutz begründenden Patente, bzgl. eines gemeinsamen Speicherbereiches für lange und kurze Dateinamen – DE 69429378 bzw. EP 0618540 – jedoch durch ein Urteil vom 26. Oktober 2006 – Akz. 2 Ni 2/05 (EU) – als für Deutschland nichtig.^{Statt <ref>-Tags (auf der Diskussionsseite ohne <references/>) hochgestellter Text, modifiziert von -- Qhx 14:55, 3. Jul. 2009 (CEST): Urteil des 2. Senates des Bundespatentgerichtes vom 26. Oktober 2006 – Akz. 2 Ni 2/05 (EU) im Volltext auf der Website des Gerichtes ([3]; 87kb; pdf).}

Das inhaltlich äquivalente US Patent dazu (US 5,758,352) besteht nach momentanem Stand (März 2009) noch weiter bis zum 5. September 2016, gilt aber nur innerhalb der USA.

Soweit ich das verstanden habe, geht es in dem Patent alleine um die langen Dateinamen in den Verzeichniseinträgen bei VFAT. Mit FAT an sich hätte das nicht wirklich etwas zu tun. --rtc 13:59, 3. Jul. 2009 (CEST)

Da dieser aRtikel auf VFAT behandelt, hat es sehr wohl auch etwas mit dem Inhalt dieses Artikels zu tun. --MrBurns 19:19, 25. Sep. 2009 (CEST)

War Memory Stick je als universelles Speicherkartenformat gedacht?

Zum Abschnitt exFAT, Unterabschnitt "Nachteile": Memory Stick ist doch ein proprietäres Format von Sony. --MrBurns 19:31, 25. Sep. 2009 (CEST)

doofe i-Norm

Wie ich ja schon in der Diskussion schrieb, führer war 1MB das, was heue 1MiB ist, und das was heute 1MB ist, waren früher 1.000.000B. Daher kann ich natürlich jedem verzeihen, der dass "korrigiert" - aber so, wie es jetzt mit beidem hin und her geworfen wird, ist es echt schlimm... Beispiel: http://de.wikipedia.org/wiki/File_Allocation_Table#FAT12 "Größe von 16 MB" "4096 Cluster angesprochen werden können." "Die Clustergröße beträgt 512 Byte bis 4096 Byte." Das macht ganze 16.77MB - oder eben 16MB [alt], macht 16MiB

Aber okay, dass geht noch (alles alt). Bei FAT16 wird es dann richtig, richtig gruselig - da ist dann irgendwo 1KB=1KiB ! Bin nicht so ganz fähig anhand "Versionen/Autoren" nachzuvollziehen, ob das nun von Anfang an auf [alt] war, oder nur jemand wie wild i's eingefügt hat, oder wie auch immer. So wie's jetzt ist, ist es einfach nur grottig. Also: LÖSCHANTRAG

D war nur ein Scherz!

btw: FAT32 ist dann wieder durchweg in [alt]

der Vorschlag kam hier schon mal: Vor einem jeden Artikel, bei dem es viel um MB/GB/TB oder auch MiB/GiB/TiB geht, sollte ein Kasten kommen, der Aufklärung schafft. sig vergessen: -- Andy386 00:07, 21. Okt. 2009 (CEST) Normen sind nicht verpflichtend. Also seh ich keien grund, eine Norm zu verwenden, dei sich eh nicht durchgesetzt ht. Deshalb bin ich gegen KiB, MiB,... Meistens weiß man, wenn man sich auskennt eh aus dem Zusammenhang, ob mit einem KB 1000B oder 1024B gemeint sind. --MrBurns 01:25, 21. Okt. 2009 (CEST)

Alles in [alt], das wurde hier so festgelegt. Daran sollten wir uns halten, solange keine gegenteilige Entscheidung getroffen wird. --Dc2 19:01, 21. Okt. 2009 (CEST)

So ist es. --HyDi Sag's mir! 20:47, 23. Okt. 2009 (CEST)

Fehler im Artikel

Im Artikel sind ein paar grobe Fehler drinnen:

Die obersten 4 Bit der FAT Einträge sind reserviert und können auch Werte !=0 annehmen, Microsoft sieht vor diese 4 Bits bei jedem Schreibvorgang zu erhalten.

Der Artikel wirft "Datencluster" und "Cluster" durcheinander. Der erste Datencluster ist Cluster Nummer 2, sämtliche Einträge beziehen sich aber auf "Cluster" und nicht "Datencluster". Beachtet man das, verschwinden die -2/+2 im Artikel weitestgehend.

Mehr findet sich hier: http://www.nondot.org/sabre/os/files/FileSystems/FatFormat.pdf

Wär schön, wenn das jemand korrigieren könnte. --188.105.113.26 21:56, 28. Okt. 2009 (CET)

Korrektur: Das mit den FAT-Einträgen bezieht sich ausschließlich auf FAT32. FAT12 und 16 reservieren die 4 oberen Bits _nicht_.

Zweifelhafte Quelle (erledigt)

Diese Quelle stand ja vorher schon drin, deshalb will ichs auch das hier nicht wegen der neuen Änderung revertieren; aber entspricht das eigentlich WP:Q? Ich kanns nicht ganz einschätzen, für mich sieht mir eher nach Blog oder Privatmeinung aus. -- Qhx 14:59, 8. Jan. 2010 (CET)

Es ermöglicht das mit Dateien, die den Namen --linux-.--- tragen.

> Es ermöglicht das mit Dateien, die den Namen --linux-.--- tragen.

fehlt da nicht etwas? (nicht signierter Beitrag von 93.219.176.205 (Diskussion) 21:35, 7. Jun. 2010 (CEST))