Diskussion:File Allocation Table/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:File Allocation Table/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:File_Allocation_Table/Archiv#Thema_1

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)

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)

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)

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))

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 (nicht signierter Beitrag von Tomiwolf (Diskussion | Beiträge) 20:36, 10. Mai 2006 (CEST))

FAT stammt von MS und nicht von Tim Patterson

FAT stammt von MS und wurde entwickelt, lange bevor Tim Patterson QDOS entwickelt hat!
Bitte MS-DOS-Artikel lesen. FAT stammt nicht von Tim Patterson
(Die vorstehenden Kommentare stammen von Ruscsi – 19:50, 17. Jan. 2008 (MEZ) – und wurde nachträglich aus dem Artikel hier herkopiert.)

Was ist „FAT“ ohne Zahlanhang?

Früher war bei einem PC unter MS-DOS während des Formatierens der IDE Festplatte einfach nur von "FAT" ohne Zahlanhang die Rede. Wurde vielleicht erst im Zuge von Erweiterungen nachträglich zwischen verschiedenen Zahlenanhängen unterschieden und welche Zahl müsste heute für dieses "FAT" angehängt werden? -- 84.132.75.67 23:37, 4. Jul. 2010 (CEST)

Bei MS "heißt" FAT bei Laufwerken bis heute automatisch FAT16 (weil zwischen FAT und FAT32 unterschieden wird), bei Disketten jedoch automatisch FAT12, d.h. das FAT-Format ist gewissermaßen vom Laufwerk abhängig. --Qhx 09:46, 28. Nov. 2010 (CET)

Wieviele dateien pro Verzeichnis

.. sind möglich? Der Artikel schweigt scheinbar hierzu. Scheinbar gibt es eine gewisse begrenzung die von der grösser der Dateinamen abhängt [4]. Bei mir war eben Ende bei ca. 20'000 dateien à 20zeichen pro dateiname. --Itu 04:48, 28. Nov. 2010 (CET)

ich verstehe die von Dir genannte "Quelle" so, dass sich die bis zu 65534 Dateien auf das Laufwerk beziehen, nicht auf einen einzelnen Ordner, 512 davon im Root. --Qhx 09:46, 28. Nov. 2010 (CET)

Der Eingangsposter fragt eindeutig "pro Ordner". Auch wären 65534 für das komplette Dateisystem wohl unmöglich wenig, wahrscheinlich selbst für eine Windowsinstallation nicht ausreichend. --Itu 11:03, 28. Nov. 2010 (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
(nicht mit einer Zeitangabe versehener Beitrag von Do ut des (Diskussion | Beiträge) 07:42, 21. Jan. 2006 (CET))

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)

Es wird Zeit, die Einheiten zu ändern!!! (nicht signierter Beitrag von 62.224.41.34 (Diskussion) 09:20, 12. Mär. 2011 (CET))

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)

Nur scheint sich da keiner so richtig dran zu halten...

Also obwohl die Diskussion schon ein wenig her ist, greif ich sie jetzt nochmal kurz auf: Als Elektroingenieur der im Entwicklungsbereich tätig ist und auch Jahre lang seine eigenen Pools administriert hat, behaupt ich mal, so ein klein wenig Erfahrung zu haben... aber diese seltsamen i-Infixe seh ich heute aber zum ersten Mal. Ganz ehrlich: Warum meinen einige Individuen sie müssten etwas, dass dermaßen unbekannt und in keiner Weise verbreitet ist, unbedingt als Wissen deklarieren? (nicht signierter Beitrag von 87.145.231.167 (Diskussion) 22:08, 28. Jan. 2011 (CET))

Weil einige Individuen es besser wissen? Und nein, dass sich keiner dran hält ist nicht korrekt. FAT ist nur einer der wenigen Artikel, wo sich bis jetzt keiner gefunden hat, der ihn auf die klassische Schreibweise zurücksetzt. --91.14.220.174 14:01, 13. Mär. 2011 (CET)

FAT 32 Nachteil ohne Beleg

Hier dürfte die Wahrscheinlichkeit gröszer sein, dass da jemand nachschaut, als im Quelltext, deshalb habe ich den (unsichtbaren) Kommentar hier her verschoben:

!-- bitte Quelle besorgen: Beim Kopieren größerer Datenmengen auf FAT32-Laufwerke ist zu beobachten, dass der Schreibvorgang für viele kleine Dateien deutlich mehr Zeit benötigt, als für wenige große Dateien mit dem gleichen Gesamtvolumen. Beim Konkurrenzformat NTFS scheint dieser Effekt deutlich geringer zu sein.--

--Empro2 16:34, 16. Mär. 2011 (CET)

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)

"Da jede Datei mindestens einen Cluster belegt, beschränkt die Anzahl der Cluster die Anzahl der Dateien"

Ich habe Dateien, die 0 Byte groß sind und auch bei "Größe auf Datenträger" 0 Byte groß sind. Die belegen dann auch keinen Cluster auf der Festplatte oder? Ist die Anzahl der Dateien dann trotzdem auf die Anzahl der Cluster beschränkt?

byteridr 06:21, 24. Sep 2010 (CET)

zu den angeblichen 32 GB: Win NT 4.0 unterstützte Fat32 mit Bordmitteln gar nicht (es gab Fremdtreiber dafür, die alle mehr oder weniger gut funktioniert haben und bei größeren Partitionen (bei mir mehrmals unter Vmware passiert) teilweise das ganze Dateisystem zerschossen haben oder zumindest die Dateien umbenannt haben, was aufs Gleiche rauskommt. Ab Win 2000 war dann ein Fat32-Treiber dabei (bei mir im Regelbetrieb), der hat meine großen Partitionen >32 GB, eine Platte mit 1 TB anstandslos und korrekt verwendet. Ich arbeite heute noch (auch unter XP) mit Fat32, weil es dort einige Reglementierungen nicht gibt, die das Dateihandling erschweren und es "bequemer" ist. Allerdings braucht man bei Win2k und höher Fremdsoftware zur Anlage, denn Microsoft beschränkt bei diesen Betriebssystemen die Neuanlage nun mal auf 32 GB. Aber nur im Festplattenmanager, nicht im Partitionstreiber!

zu den 0 kB-Dateien: ich habs grad mal ausprobiert, bei mir belegen 0kB-Dateien tatsächlich 0kB, auch auf dem Datenträger. Füge ich ein Zeichen hinzu, werden die Dateien mit 1 kB und 32 kB auf dem Datenträger angegeben. Ich nehme also an, dass bei der Neuanlage einer Datei erst mal nur in der Fat ein Speicher reserviert wird, der aber im Dateibereich nur dann belegt wird, wenn es Daten gibt. Wahrscheinlich könnte man also auf einer kleinen Partition den ganzen Speicher mit einer Datei zumüllen und dann trotzdem noch jede Menge "Dateien" (die in Wirklichkeit gar nicht existieren) anlegen, d.h. in die Fat eintragen. Ganz sicher weiß ichs allerdings nicht, aber nach diesem Test wird es wahrscheinlich so sein. --Qhx 08:49, 24. Sep. 2010 (CEST)

Jein. Ein Cluster nimmt den eigentlichen Inhalt einer Datei auf. Wenn der Null ist, wird nur ein Verz.eintrag angelegt, der nimmt je nach FAT-Version nur ein paar Byte in Anspruch (32 bei Fat32, genauer 28+4, die oberen 4 bit sind reserviert), bzw gar nix da bei Fat12/16 die FAT schon eine fixe Grösse hat, dort werden einfach nur die Werte eingetragen. Startcluster ist bei diesen Dateien immer 0 im Verz.eintrag, in der FAT steht die Kennung EOC(=End of Cluster Chain) die je nach FAT-Typ unterschiedlich ist 0x0FF8,0xFFF8,0x0FFFFFF8 (in der spec steht auch 0x0FFF,0xFFFF,... das scheint ein Fehler zu sein) für FAT-12/16/32 oder der letzte Cluster der die EOC trägt, dieser letzte (und einzige) Cluster wird dann von der Datei auch belegt. Wenn man eine leere Datei anlegt wird das wie in der ernste Möglichkeit gemacht, die zweite Möglichkeit vermutlich beim Nullsetzen einer Datei, beides ist legal aber implementierungsabhängig, wie so vieles bei FAT12/16/32. Theoretisch kann man eine Platte mit leeren Dateien füllen was aber bei FAT12/16 an der fixen Grösse der FAT praktisch scheitert, bei FAT32 an der maximalen Anzahl an Dateien falls man das mit einer grossen Platte ausnutzen kann, bin zu faul um das auszurechenen. (nicht signierter Beitrag von 84.164.134.129 (Diskussion) 21:48, 27. Mär. 2011 (CEST))

Wie funktioniert löschen von dateien?

Ist das klar definiert oder kann das jeder Implementierer selber nach eigenem Gusto machen? Wenn ich mich recht erinnere machte das z.B. MS-DOS so, dass das erste Zeichen im Dateiindex mit einem ungültigen Zeichen überschrieben wurde, wie das mit den CLustern gemacht wurde kann ich mir irgendwie nicht vorstellen, weil recoverytools viele Dateien problemlos wiederherstellen konnten. Also müssen irgendwo noch die entsprechenden Cluster vermerkt sein (in der 2. FAT) sonst geht das nicht, nat. vorausgesetzt dass keine andere Datei inzwischen die entspr. Cluster belegt hat.
(nicht signierter Beitrag von 84.164.137.92 (Diskussion) 23:03, 13. Mär. 2011 (CET))

Wie du schon schriebst: Der Verzeichniseintrag wird entsprechend markiert (1. Zeichen des Dateinamens auf 05_hex) und die Cluster, die die Datei belegte, werden in beiden FATs als 'unbelegt' markiert. Undelete-Programme gehen einfach davon aus, dass die Datei unfragmentiert ab dem Startcluster (der noch im Verzeichniseintrag steht) gespeichert war. Sehr oft haben sie Glück damit. --RokerHRO 23:33, 28. Mär. 2011 (CEST)

Stammverzeichnis und Unterverzeichnisse

Unter Zusammenspiel wird erklärt, dass die cluster über die FAT verkettet sind, es wird aber nicht erklärt, wie man von einem cluster zum FAT-Eintrag findet, das Zusammenspiel ist unterbrochen. Im Artikel "Cluster" steht auch nichts. Weiss das wer, oder habe ich etwas übersehen? --Bertium 21:39, 14. Sep. 2011 (CEST)

Ich habe das jetzt mal geändert. Nicht die cluster, sondern die FAT-Einträge sind verkettet. Die cluster sind nicht direkt verkettet, sonst würde der Zugriff ja gar nicht mehr möglich sein. --Bertium 11:09, 15. Sep. 2011 (CEST)

Das ist ungeschickt formuliert. Denn die FAT-Einträge sind nicht verkettet. Die FAT ist einfach ein Array, die Elemente dieses Arrays sind Clusternummern. Die Einträge der FAT bilden eine Clusterkette. Oder anders formuliert: Über die FAT-Einträge lässt sich zu einer gegebenen Datei die zugehörige Clusterkette ermitteln.

--RokerHRO 14:53, 15. Sep. 2011 (CEST)

65536 Verzeichniseinträge pro Verzeichnis

Dieses Limit fehlt irgendwie im Artikel. --RokerHRO 21:23, 10. Jun. 2011 (CEST)

Ausserdem les ich da nur was von 512, was sogar für Windows etwas niedrig erscheint.... --Nicht signierter Beitrag von Itu, 2012-02-04T19:10:10‎

Bei FAT12 und FAT16 gibt es, außer für das Wurzelverzeichnis, auch kein Limit bis zur maximalen Zahl der (noch) verfügbaren Datencluster. Für das Wurzelverzeichnis gibt es ein festes Limit, das im BPB eingetragen ist. Zwar könnte man versucht sein, dort einfach einen anderen Wert einzutragen und die Formatierung entsprechend zu ändern (der Platz für das Wurzelverzeichnis ist vorallokiert), aber die meisten Betriebssysteme (insbesondere die von Microsoft und IBM) werden nur mit ganz bestimmten Werten klarkommen, so daß es hier bei Wechselmedien mit Medientyp F9h..FFh und bei Festplatten mit Medientyp F8h in der Praxis keine Wahl gibt. Lediglich beim Medientyp F0h sind einige dieser Betriebssysteme etwas flexibler und akzeptieren auch andere Werte sofern bestimmte Randbedingungen eingehalten werden. Der Wert für Medientyp F8h beträgt gerade 512 Einträge, wobei Einträge sich hier auf Verzeichniseinträge für kurze 8.3-Dateinamen bezieht. Lange VFAT-Dateinamen benötigen je nach Länge zusätzliche Einträge (typischerweise zwischen 1 und 20 zusätzlich, theoretisch bis zu 31 zusätzlich).

Bei FAT32 ist das Wurzelverzeichnis ein ganz normales Verzeichnis, insofern gibt es hier keine feste Beschränkung mehr wie noch bei FAT12 und FAT16. Im Prinzip, d.h. vom Design des Dateisystems her, gibt es also bis zur maximalen Zahl der (noch) verfügbaren Datencluster kein Limit, und da diese Zahl bei FAT32 sehr hoch ist, wird man selten an dieses Limit stoßen. Allerdings gibt es auch hier eine Ausnahme: Microsoft-Betriebssysteme beschränken die Zahl der Dateien in einem Unterverzeichnis auf maximal 65534 (nicht 65536) Dateien, d.h. es stehen maximal so viele Verzeichniseinträge pro Verzeichnis zur Verfügung. Bei Verwendung langer Dateinamen verringert sich diese Zahl entsprechend. Diese Grenze ist aber künstlich, d.h. sie existiert nur in Microsofts Treibern (wohl aus Performance-Gründen); sie ist keine Grenze, die in den Datenstrukturen des Dateisystems selbst verankert wäre. Dementsprechend ist es unter den meisten Fremdimplementationen von FAT32 problemlos möglich, auch mehr als 65534 Dateien in einem Verzeichnis abzulegen (warum auch immer man das tun sollte), diese können dann halt nur unter solchen Fremdsystemen gelesen werden. Ab und zu liest man im Netz auch von Beschränkungen in anderen Betriebssystemen; ich kann mir lediglich vorstellen, daß hier aus Kompatibilität zu Microsoft ebenfalls künstliche Schranken eingebaut wurden, denn wie gesagt, im Dateisystem selbst gibt es solche Limits nicht.

Was nun die Zahl der (noch) verfügbaren Datencluster angeht, diese Zahl hängt von diversen Faktoren ab. Zunächst einmal vom Dateisystemtyp FAT12, FAT16 und FAT32. Bei FAT12 stehen maximal 2^12 - reservierte Cluster, bei FAT16 2^16 - reservierte Cluster und bei FAT32 2^28 - reservierte Cluster zur Verfügung. Reservierte Cluster sind die Cluster 0 und 1, sowie Cluster ab einschließlich FF8h, FFF8h und 0FFFFFF8h aufwärts. Bei FAT12 ist bei Microsoft/IBM-Betriebssystemen auch Cluster FF0h für interne Zwecke in Benutzung und darf keinesfalls in einem Dateisystem vorkommen (sonst "kracht" es), Fremdsysteme behandeln FF0h hingegen genauso wie FF1..FF5h sowie FF6h und FF7h, die ebenfalls reserviert sind. Gleiches gilt analog auch für FAT16 und FAT32, nur daß der Cluster ...F0h hier nur reserviert, aber nicht intern benutzt wird. Will man auf der sicheren Seite sein, kommen also nur Cluster 002h/0002h/00000002h bis FEFh/FFEFh/0FFFFFEFh als Datencluster in Frage. Nimmt man nun an, daß eine Datei nicht größer als die Clustergröße ist, so verbraucht jede Datei einen dieser Datencluster. Bei größeren Dateien reduziert sich das entsprechend. Bei FAT12 und FAT16 dürfen wir nicht vergessen, daß wir mindestens ein Unterverzeichnis brauchen, das ebenfalls mindestens einen Datencluster belegt. Bei FAT32 ist das, wie gesagt, nicht notwendig. Grundsätzlich ist es aber so, daß Verzeichniseinträge ebenfalls Datencluster belegen. Jeder (8.3) Verzeichniseintrag ist 32 Bytes lang und es passen demnach x solche Einträge in einen Cluster der Größe y. Die für die Verzeichniseinträge benötigten Cluster stehen also ebenfalls nicht mehr als freie Datencluster zur Verfügung. Daraus kann man sich nun für ein konkret vorliegendes Medium ausrechnen, wieviele Dateien es maximal speichern könnte; und dies ist dann unter Berücksichtigung der obigen Einschränkungen auch die obere Grenze für die Zahl der Dateien in einem Unterverzeichnis. --Matthiaspaul 12:23, 6. Feb. 2012 (CET)

Danke für die Info, daß die Anzahl der Verzeichniseinträge bei Windows Betriebssystemen begrenzt ist. Bin nämlich selber gerade darauf gestoßen (mit der vielsagenden Fehlermeldung "Das Verzeichnis oder die Datei kann nicht erstellt werden."; habe ca. 10000 Dateien mit ca. 58 Byte langen Dateinamen). Daher die Bitte: kannst Du diesen Fakt auch im Artikel einfließen lassen? Danke! 93.194.130.237 19:18, 15. Feb. 2012 (CET)

exFAT auslagern

Das Dateisystem exFAT sollte in einen eigenen Artikel ausgelagert werden, denn exFAT hat praktisch nichts mit FAT12, FAT16 und FAT32 gemein, und die Behandlung in einem Artikel führt viele Leser in die Irre, die hier eine wie auch immer geartete Fortführung des bisher bekannten FAT-Dateisystems vermuten. Der "Ruhm" von FAT12, FAT16 und FAT32 färbt sonst unberechtigterweise auf exFAT ab, was ich gerade im Hinblick darauf, daß exFAT ein patentgeschütztes Dateisystem ist, dessen Spezifikationen nicht offengelegt wurden und wo Fremdimplementierungen Lizenzzahlungen an Microsoft erfordern (was eine legale Implementierung in "freien" Betriebssystemen unmöglich macht), für sehr wichtig halte, gerade auch weil SDXC und Memorystick XC exFAT zu ihrem Dateisystem erhoben haben und vielen Anwendern die weitreichenden Folgen nicht bewußt sind. --Matthiaspaul 13:02, 6. Feb. 2012 (CET)

FAT8

Laut en:File_Allocation_Table#Original_8-bit_FAT hatte das ursprüngliche FAT 8 bit und wurde 1977 als Teil von Microsoft BASIC für den 8080 eingeführt. --MrBurns 14:15, 22. Feb. 2012 (CET)

Es ist richtig, daß das ursprüngliche FAT-Format 8-bittig war (1977, nicht 1997 ;-), aber es hieß nicht FAT8 und wir sollten diesen Namen deshalb auch nicht verwenden. Darüberhinaus wurde dieses Format weder von Q-DOS/86-DOS, noch von MS-DOS/PC DOS und alternativen DOSen je unterstützt, ist insofern lediglich historisch interessant. --Matthiaspaul 14:31, 22. Feb. 2012 (CET)

Ich hab FAT8 nur als Überschrift gewählt, weil mir nichts besseres eingefallen ist, es heiß wohl einfach nur FAT ohne Zusatz. Es ist wohl deshalb relevant, weil die späteren FAT-Versionen darauf aufbauen, auch wenn es für ein anderes System (eben Microsoft BASIC statt DOS) und ursprünglich eine andere CPU-Architektur entwickelt wurde. Es gab allerdings später auch ein 8-bit FAT für 8086-Version von MS-BASIC. Und den Tippfehler bei der Jahreszahl hab ich korrigiert. --MrBurns 01:32, 23. Feb. 2012 (CET)

Opps, meine Antwort konnte man schnell negativ verstehen, dabei war sie eigentlich als Unterstützung Deiner Aussage gemeint... Sorry. Mich würde übrigens mal ein Diskimage einer Floppy eines dieser BASIC-Rechner in diesem 8-bittigen FAT-Format interessieren, denn es steht zu vermuten, daß es außer dem Grundprinzip nicht viele Gemeinsamkeiten mit späteren FAT-Varianten wie z.B. FAT12 gab und daß insbesondere die Datenstrukturen sich unterscheiden. Einen IBM-kompatiblen Bootsektor gab es damals noch nicht und einen BIOS Parameter Block ebensowenig. Aber auch die Verzeichniseinträge könnten noch anders ausgesehen haben, denn selbst DOS 1.0 unterstützte noch keine Read-Only- und Volume-Attribute, keine last modified time und natürlich auch noch keine Unterverzeichnisse. Bei so vielen ungenutzten Bereichen erscheint eine 32 Byte große Datenstruktur dafür schon fast Overkill... Und wie in diesem frühen Dateisystem mit Cluster 0, 1 und ganz hohen Clusterwerten verfahren wurde, welche Werte zur Markierung freier oder defekter Cluster verwendet wurden, ist mir auch nicht bekannt, das wäre aber interessant zu wissen, um einige "Eigentümlichkeiten" bei der Wertewahl bei den späteren FAT-Varianten zu erklären. --Matthiaspaul (Diskussion) 15:03, 3. Mär. 2012 (CET)

Kleine Ergänzung: Inzwischen konnte ich eine ganze Reihe weiterer Details zu Frühformen des FAT-Dateisystems (d.h. vor dem, was wir allgemeinhin als "FAT12" aus DOS etc. kennen) in Erfahrung bringen und habe den aktuellen Stand der Nachforschungen im FAT-Artikel der englischsprachigen Wikipedia eingearbeitet. Derzeit stehe ich in Korrespondenz mit Marc McDonald, und hoffe so, eine vollständige Beschreibung der 8-bittigen FAT-Variante (die ihm zufolge einfach "FAT structure" genannt wurde) in Stand-alone Disk BASIC und der 10-, 12- und 16-bittigen Varianten in MIDAS zu bekommen und die verbliebenen Fragen zur Wahl einiger "Magics" bzw. Eckwerte klären zu können, die sich nicht von selbst aus der späteren Implementierung in DOS heraus erklären. Zwar basierten diese Frühformen alle auf dem gleichen Prinzip, aber in einigen Punkten unterschieden sie sich deutlich von dem, was Tim Paterson in QDOS/86-DOS implementiert hat, so daß die Medien nicht austauschbar sind. --Matthiaspaul (Diskussion) 21:23, 25. Sep. 2012 (CEST)

Die bisherigen SDHC- und Memory-Stick-PRO-HG-Duo-Standards stoßen bei 32 GiB an ihre jeweiligen Systemgrenzen.

Welche Grenze ist das? An FAT32 kann es nicht liegen, da im Artikel ja steht, dass das Dateisystem ca. 8,8 Terabyte groß sein kann. (nicht signierter Beitrag von Graf Westerholt (Diskussion | Beiträge) 16:06, 26. Jul 2014 (CEST))

Die 32 GiB sind nur eine künstliche Beschränkung vom Windows-Formatierungstool. Bei Software von Drittanbietern existiert diese Beschränkung nicht. Das theoretische Maximum dürfte 8 TiB sein, allerdings kenne ich kein Programm, das unter Windows mehr als 2 TiB formatieren kann. --MrBurns (Diskussion) 13:26, 19. Nov. 2014 (CET) PS: Was die Speicherkarten betrifft: der unterschied zwischen SDHC und SDXC ist nicht nur das Dateisystem, die Adressierung funktioniert bei SDXC auch anders als bei SDHC, weil die Addressierungsmethode von SDHC nur bis 32GB funktioniert. Man kann natürlich eine SDXC-Karte auch auf FAT32 formatieren und die funktioniert dann normalerweise auch in SDXC-fähigen Geräten, nur geht die FAT32-Formatierung halt nicht mit dem Windows-Formatierungstool. --MrBurns (Diskussion) 13:34, 19. Nov. 2014 (CET)

Beschränkungen des FAT Dateisystems

Beschränkungen des FAT Dateisystems sind bei weitem nicht vollständig und sollten erweitert werden. zB ist die max Anzahl der Dateien im Root Verzeichnis bei FAT16 nicht unbedingt 512. Durch Verwendung langer Dateinamen kann das drastisch redzúziert werden zB auf 128. Leider fehlt mir persönlich der techn. Background um das RICHTIG in den Artikel zu editieren. --Downhillschrott (Diskussion) 13:55, 20. Sep. 2012 (CEST)

Die maximale Anzahl der Dateien im Rootverzeichnis bei FAT12/16 hängt nicht nur davon ab, ob lange Dateinamen verwendet werden, sondern auch davon, wie groß das Rootverzeichnis ist (das steht aber eh schon im Artikel), 512 bei FAT16 Einträge sind nur der Standardwert unter DOS. --MrBurns (Diskussion) 17:50, 20. Sep. 2012 (CEST)

Theoretisch ist die maximale Dateigröße...

Die maximale Dateigröße ist einzig und allein dadurch beschränkt, dass sie als 32-Bit-Wert gespeichert wird. Da die FAT eine Tabelle ist, die für jeden Cluster den darauf folgenden Cluster speichert, könnte eine Datei-Kette aus den vollen 2^28 Clustern bestehen (allerdings bei falscher Dateigröße). Die FAT wäre dann 4 Bytes * 2^28 = 1 GB groß, und um den letzten Cluster dieser Datei anzuspringen müssten zuerst die vollen 1GB gelesen werden. Um das Ende einer 4GB-Datei anzuspringen müssen mindestens 512kb der FAT gelesen werde (bei 32kb Clustern) oder 4MB (bei 4kb Clustern). (ohne Benutzername signierter Beitrag von 188.109.97.142 (Diskussion))

Die Beschränkung der Dateigröße bei FAT32 kommt nicht vom FAT selbst, sondern von der Norm für den Verzeichniseintrag, die für die Dateigröße 32 bit reserviert, also kann die Dateigröße nicht größer werden als 2^32 Bytes - 1 Byte. Und das sind dann eben 4GB - 1 Byte. --MrBurns (Diskussion) 11:40, 18. Dez. 2012 (CET)

Richtig, dennoch wäre es möglich, von der Norm abzuweichen und größere Dateien einfach zu erlauben. Man müßte nur den Wert für die Dateigröße anders interpretieren: Z.B. könnte man Werte > 2^32-2^16 als Sonderfall behandeln, und die tatsächliche Dateigröße aus der Länge der Clusterkette plus die untersten 16 Bit des Dateigröße errechnen. Deswegen "theoretisch". --188.109.97.142 (21:38, 18. Dez. 2012 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Ja klar, man könnte auch das "reservierte" Byte beim Offset 0x0C verwenden, um den Wertebereich für die Dateigröße auf 40 bit zu vergrößern, was die maximale Dateigröße auf 1TB erhöhen würde, aber das wäre dann nicht standardkonform, da der FAT32-Standad eben auch die Verzeichniseinträge festlegt und würde zu Kompatibilitätsbproblemen bei Dateien mit 4GB oder mehr führen. Microsoft hätte sowas natürlich machen können um FAT32 2.0 einzuführen, abe rman hat sich dafür entschieden, statt dessen exFAT einzuführen, also ist diese Möglichkeit irrelevant. --MrBurns (Diskussion) 22:25, 18. Dez. 2012 (CET)

(Fast) genau das ist ja bei "FAT32+" passiert, einer Erweiterung des FAT32-Dateisystems, die allerdings bisher nur von einigen Versionen von DR-DOS und sehr wenigen Anwendungen unterstützt wird. Für FreeDOS war das auch mal geplant, wurde aber meines Wissens im offiziellen Kern nicht übernommen.

Dabei werden die höherwertigen Bits der Dateigröße in sechs Bits des Bytes an Offset +0Ch gespeichert. Die Bits 3 und 4 bleiben dabei ungenutzt und unverändert, denn diese werden von anderen Betriebssystemen wie der Windows NT-Familie genutzt. Damit sind dann im ansonsten unveränderten FAT32-Dateisystem Dateien bis 256 GB-1 Byte möglich. Eine entsprechende API-Erweiterung gibt es natürlich auch. Damit solche übergroßen Dateien halbwegs sicher vor Zerstörung durch nicht "FAT+"-fähige Betriebssysteme / Tools sind, gibt es allerdings einige Dinge zu beachten (es existieren verschiedene optionale Proposals in Bezug auf die Versionsnummer des FAT32-Dateisystems und die semantische Umwidmung bestimmter Attributkombinationen). Wen's interessiert, der technische Teil des FAT-Artikels der englischen Wikipedia beschreibt das ziemlich im Detail.

Es gibt natürlich besser dafür geeignete Dateisysteme, zu denen sicherlich auch exFAT gehört. Nur: exFAT unterscheidet sich von FAT12, FAT16 und FAT32 so stark, daß man den überwiegenden Teil des vorhandenen FAT-Dateisystemcodes dafür nicht weiterverwenden kann. Damit scheidet eine native Implementierung in Lightweight-Systemen wie DOS aus. Hinzu kommt die Problematik, daß die Implementierung/Nutzung von exFAT proprietär, patentgeschützt und lizenzkostenpflichtig ist, was eine Verwendung in freien Systemen ebenfalls ausschließt. Insofern ist FAT32+ schon eine interessante Alternative, die sich mit wenigen Bytes zusätzlichen Codes in jedem Betriebssystem, das FAT32 unterstützt, implementieren läßt. Unter DOS wäre dann wenigstens ein langsamer Zugriff möglich, andere Systeme, bei denen der Real-Mode-Speicherbedarf keine Rolle spielt, können durch geeignete Aufbereitung der im Speicher gehaltenen FAT-Teile auch mit supergroßen FAT32-Systemen und entsprechend großen Dateien recht flott arbeiten, so daß sich hier der Vorteil von Dateisystemen, die direkt bessere On-Disk-Datenstrukturen mitbringen, relativiert. Werden nur wenige sehr große Dateien linear auf ein frisch formatiertes Medium geschrieben (typischer Anwendungsfall z.B. bei DSLRs und Videokameras), ist auch die Performance von FAT32+ durchaus akzeptabel. Solange aber nicht wenigstens noch Linux FAT32+ aufgreift (was ja sehr einfach wäre), bleibt das eine Insellösung, und damit ist die dreißigjährige Ära, in der wir ein praktisch übergreifendes Austauschformat (nämlich FAT) nutzen konnten, wohl leider in Bälde beendet. --Matthiaspaul (Diskussion) 12:30, 19. Dez. 2012 (CET)

Zu den Patenten: NTFS ist auch durch Patente geschützt, trotzdem ist es durch Reverse Engineering gelungen, Microsot-unabhängige Treiber für NTFS zu entwickeln, die keine Patente verletzen. Der Grund ist wohl, dass das Dateisystem selbst nicht patentierbar ist, sondern nur die konkrete Methode, mit der auf dieses zugegriffen wird, was durch die Entwicklung einer alternativen Methode umgangen wurde. Eine derartige alternative Methdoe ist für exFAT wohl noch nicht bekannt (die Entwickler der schon fertigen exFAT-MacOS-X-Treiber sowie der exFAT-Linux-Treiber, die derzeit entwickelt werden, haben von MS eine Lizenz bekommen), aber exFAT ist relativ neu und bei NTFS hat es sehr lange gedauert, bis es auf nicht-Windows-Betriebssystemen lauffähig wurde. Aber natürlich besteht die Gefahr, dass es ähnlich lange dauert, bis es für exFAT MS-unabhängige Treiber gibt (im schlimmsten Fall bis nach Ablauf der Patente). Zu den Kompatibilitätsproblemen: dass normale Anwendungen bei FAT32+ die Dateien mit >4GB überschreiben ist ausgeschlossen, da diese Cluster im FAT ja als belegt markiert sind. Probleme gibts aber bei Dateisystemtools, die FAT32+ nicht kennen, diese sehen dann Cluster, die als belegt markiert sind, aber ihrer Ansicht nach nicht zu einer Datei gehören und heben daher entweder die Reservierung auf (entweder automatisch oder nachdem der User gefragt wurde). Soviel ich weiß kann das nicht unterbunden werden. --MrBurns (Diskussion) 13:07, 19. Dez. 2012 (CET)

"Zu den Kompatibilitätsproblemen: dass normale Anwendungen bei FAT32+ die Dateien mit >4GB überschreiben ist ausgeschlossen, da diese Cluster im FAT ja als belegt markiert sind." Leider ist das nicht so. Ein Betriebssystem, das von FAT32+ nichts weiß, wird die MSBs ignorieren und das Öffnen eines unterschiedlich großen Teilstücks am Anfang der Datei erlauben (modulo). Wenn eine Anwendung jetzt die Dateilänge verändert, wird das Ende der Datei abgeschnitten und findet sich als "lost clusters" auf dem Medium wieder.

Ein Vorschlag, das zu verhindern, geht dahin, die FAT32-Unterversionsnummer von 0.0 auf 0.1 zu erhöhen. Sauber programmierte Dateisystemtreiber, die eine Version 0.1 nicht kennen, sollten das Dateisystem dann nicht mounten - einige Systeme tun es dennoch, dann müßte man noch auf einen "secured" (oder "hidden") Partitionstyp ausweichen, um das versehentliche Mounten zu verhindern. "FAT32+"-fähige Systeme würden hingegen das Dateisystem mounten und über das alte API nur den Zugriff auf Dateien erlauben, die nicht übergroß sind. Nur über das neue API können übergroße Dateien genutzt werden. (Für FAT16+ läßt sich dieser Schutz nicht realisieren, außer man schiebt einem FAT16B-Volume ein FAT32-EBPB unter (was technisch zwar erlaubt ist, aber absolut "Non-Standard"). Aber der Praxisnutzen von FAT16+ ist sowieso eher theoretischer Natur, insofern sollte es daran nicht scheitern.)

Ein weiterer Vorschlag geht dahin, alle "FAT+"-Dateien optional mit System-, Hidden- und/oder Read-Only-Attributen zu versehen. Normale Directory-Scans würden Dateien mit Hidden-Attribut überlesen. Selbst wenn man die Datei öffnet, kann zwar der Anfang der Datei zum Teil gelesen werden, (was eine Anwendung schlimmstenfalls zum Absturz bringen könnte, wenn sie Strukturen einzulesen versucht, die über dieses Teilstück hinausgehen und die Datei dann scheinbar unerwartet abbricht - eine sauber programmierte Anwendung sollte jedoch auch mit Disk-Fehlern klarkommen können). Wegen eines gesetzten Read-Only-Attributs kann nicht schreibend auf eine Datei zugegriffen werden, insofern aber auch kein Schaden angerichtet werden. Dateien mit gesetztem System-Attribut dürfen hingegen definitionsgemäß nicht auf dem Medium verschoben werden, insofern sollten Disk-Tools wie Defragmentierer solche Dateien in Ruhe lassen (Tools wie CHKDSK/SCANDISK bleiben aber kritisch). Alle drei Attribute zu setzen ist immer noch kein perfekter Schutz (zumal man die Attribute ja auch jederzeit später wieder ändern kann, sofern - unter DR-DOS - kein Paßwortschutz besteht), aber es stellt das Maximum dar, was man unter Wahrung der Rückwärtskompatibilität im Rahmen des klassischen FAT-Dateisystems erreichen kann.

Damit "FAT+"-fähige Betriebssysteme trotzdem mit solchen Dateien arbeiten können, dürfen sie das Hidden- und Read-Only-Attribut natürlich nicht als solches behandeln, wenn über das neue API auf übergroße Dateien zugegriffen wird. Damit man auch für "FAT+"-Dateien soetwas wie einen Schreibschutz realisieren kann, kann man zusätzlich noch das System-Attribut setzen. In diesem Fall würde ein gleichzeitig gesetztes Read-Only-Attribut bei einer "FAT+"-Datei nicht ignoriert - Analoges für die Kombination von System- und Hidden-Attribut. So wäre zwar bei "FAT+"-Dateien nicht jede bisher mögliche Attributkombination einstellbar, aber alle wichtigen Eigenschaften der Attribute sind immer noch abbildbar. Das zusätzlich gesetzte System-Attribut dürfte in den wenigsten Fällen stören.

(Das Ganze ist keineswegs so komplett abwegig, wie es zunächst klingen mag: DR-DOS macht schon von jeher etwas sehr Ähnliches mit dem Hidden-Attribut: Dateien, Verzeichnisse (und Volumes) können unter DR-DOS bekanntlich mit Paßwörtern vor Lese-/Schreib-/Löschzugriffen geschützt werden, mit optionaler Multiuser-Security auch auf World/Group/Owner-Ebene. Bei paßwortgeschützten Dateien wird standardmäßig das Hidden-Attribut gesetzt, damit diese Datei unter fremden Betriebssystemen, die nichts von dieser Erweiterung wissen, zumindest nicht angezeigt werden - zugreifen kann man trotzdem (insofern ist dieser Schutz löchrig), sofern nicht das ganze Volume selbst auch paßwortgeschützt wurde. DR-DOS zeigt paßwortgeschützte Dateien trotz Hidden-Attribut an, wenn man die Datei verstecken will, muß man zusätzlich noch das System-Attribut setzen. Wenn man das Hidden-Attribut zurücksetzt, bleibt der Paßwortschutz unter DR-DOS natürlich erhalten.) --Matthiaspaul (Diskussion) 23:41, 19. Dez. 2012 (CET)

Stimmt, an das Problem hab ich nicht gedacht, da ich mich gedanklich nur mit der Situation beschäftigt habe, dass im inkompatiblen Betriebssystem neue Dateien geschrieben werden aber nicht mit der, dass vorhandene Dateien mit >4GB überschrieben werden. In letzterem Fall kann natürlich nichts passieren, weil die entsprechenden Cluster als belegt markiert sind. Das Problem mit den Dateisystemtools lässt sich übrigens nicht durch Schreibschutz beheben, da diese das Schreibschutzattribut bei der Fehlerkorrektur irgnorieren. --MrBurns (Diskussion) 01:21, 20. Dez. 2012 (CET)

Bei exFAT steht noch sowas wie "exFAT unter Linux wird es nicht geben" bzw. "Lizenz notwendig", was ja (zumindest mittlerweile) offensichtlich falsch ist.--Mideal (Diskussion) 12:29, 19. Nov. 2014 (CET)

Ich denke, um den ExFAT-Treiber unter Linux zu nutzen, braucht man noch immer eine Lizenz. Deshalb ist er auch nicht bei jeder aktuellen Linux-Distribution dabei. --MrBurns (Diskussion) 13:46, 19. Nov. 2014 (CET)

exFAT und freie Betriebsysteme

„Wegen der nicht offengelegten Interna und der erheblichen Unterschiede zu klassischen FAT-Dateisystemen ist für viele aktuelle freie Betriebssysteme auch im Rahmen von Treiberaktualisierungen nicht mit einer Unterstützung von exFAT zu rechnen.“ Das scheint veraltet zu sein: [5] [6].

Oder sehe ich das falsch? --Erschaffung (Diskussion) 20:53, 24. Dez. 2016 (CET)

Soviel ich weiß gibts exFAT-Treiber nicht für Linux allgemein, sondern nur für bestimmte Distributionen, für die Microsoft auch Lizenzgebühren erhält. --MrBurns (Diskussion) 17:38, 25. Dez. 2016 (CET)

Normalerweise spielt es ja keine Rolle, ob Software kostenpflichtig lizenziert wird oder frei verfügbar ist. Windows und MS-Office sind ja klassische Gegenbeispiele, dass Closed-Source und Kauflizenzen sogar sehr erfolgreich sein können, also ist der hier formulierte Zusammenhang in dieser Form Käse, zumindest aber frei formulierter POV, und sollte gelöscht werden. Stattdessen könnte man eventuell schreiben, dass es sich schlicht (noch) nicht durchgesetzt hat. (Auch wenn ich jetzt ad-hoc grad keinen Beleg dafür zur Hand hab.) --H7 (Diskussion) 18:28, 25. Dez. 2016 (CET)

In gewissen Nischen ist exFAT durchaus erfolgreich, z.B. bei SDXC oder auch bei größeren USB-Sticks (wegen dem 4GB-Dateigrößenlimit von FAT32 und weil NTFS für Wechseldatenträger wegen Journaling etc. nicht besonders gut geeignet ist). --MrBurns (Diskussion) 18:43, 25. Dez. 2016 (CET)

Naja. Also 1. stimmt es, dass exFAT nicht in den Kernel integriert wird/werden kann, und zwar ausschließlich deshalb, weil Microsoft es patentiert hat und gleichzeitig exFAT nicht frei ist. 2. gibt es dennoch eine Möglichkeit, unter Linux und Mac OS X zu exFAT zu kommen, und zwar über einen per FUSE eingebundenen freien exFAT-Treiber, der jedoch bei den allermeisten Linux-Distributionen wegen der angesprochenen Patente nicht von Haus aus ausgeliefert werden dürfte. Siehe diesen Golem-Beitrag.

Der Vergleich mit proprietären Betriebssystemen und Anwendersoftware (Windows und Office) hinkt. Man muss sich ja auf einem Computer nicht ein kostenpflichtiges Betriebssystem installieren um definierte Standards nutzen zu können. So kann man sich beispeilsweise ein JPEG-Bild auch auf freien Betriebssystemen und freien Programmen anschauen und verwenden. Bei exFAT ist das allerdings anders: exFAT ist gemäß Spezifikation das Dateisystem für SDXC (SD-Karten >32GB). Das wird dann lustig, wenn man eine solche SD-Karte in einem Gerät benutzen will, für welches keine Lizenz von Microsoft erworben wurde. Beispiel: Raspberry Pi – will man für diesen Kleinstcomputer eine SDXC-Karte für’s Betriebssystem nutzen, muss die Karte entgegen der Spezifikation nicht in exFAT, sondern in FAT32 formatiert werden, wie hier beschrieben (englisch).

Wenn man schon vergleicht, dann kann man exFAT eher mit MP3 vergleichen: auch diese Codecs waren viele Jahre lang (und sind es teilweise noch heute) nicht im Lieferumfang von Linux-Distributionen (und vermutlich aus demselben Grund auch nicht bei BSD-Unices) enthalten, weil die Codecs eben patentiert sind und man Lizenzgebühren zahlen müsste – auch dann, wenn man sich nur MP3s anhören können will. Dasselbe gilt für die CSS-Verschlüsselung von DVDs – und unter Linux wäre es somit nicht gratis möglich, Video-DVDs anzusehen. Bei BluRay besteht dasselbe Problem bekanntlich immer noch, weil es noch nicht reverse-engineered wurde. Bei exFAT ist das dann bedauerlich, wenn man die Fotos von einer Kamera per SD-Karte+Slot im Computer übertragen können will, dieser aber das per Spezifikation erforderliche exFAT aus patentrechtlichen Gründen nicht lesen kann.

‣Andreas•⚖ 21:10, 25. Dez. 2016 (CET)

Maximale Größe von FAT32

Im Text und in der Spalte rechts steht "Größe des Dateisystems: 8 TiB (mit 32 KiB Clustergröße)".
Dies ist nicht richtig.
Gund ist, daß zum FAT32 Dateisystem der Boot Parameter Block "BPB_TotSec32" gehört, der in eimen 32 Bit Wert die Anzahl der Sektoren (!) enthält.
Da typischerweise die Sektorengröße bei Festplatten 512 Bytes beträgt, ergibt sich ein maximaler Wert von 2 TiB. Leider ist dies der limitiernde Faktor und nicht die Clustergröße von 32 KiB (dt.: Zuordnungseinheit), wie im Text steht (2¹⁵ · 2²⁸ = 2⁴³ Byte)
Ich würde das demnächst im Text ändern.
Übrigens ist das auch in der englischen Seite so korrekt dargestellt.
Fragen, Einwände?
Quellen und Referenz (die man meiner Meinung nach im Artikel aufnehmen sollte):Microsoft FAT Spezifikation
2001:7F0:400C:0:0:0:0:4 10:36, 13. Aug. 2018 (CEST)

"modern"??

"Es gibt mehrere moderne DOS-Systeme, die FAT32 nativ unterstützen" Modern = 1996 eingeführt?? Seit ihr noch nicht im 21. Jd angekommen?? (nicht signierter Beitrag von 47.71.8.247 (Diskussion) 14. Mai 2019, 08:45‎)

Es ist missverständlich formuliert. Modern sind die Betriebssysteme, die FAT32 nach wie vor unterstützen, also z.B. Windows 10, aktuelle Linux- oder UNIX-Systeme, darunter viele embedded-Systeme, also Kameras, Multimedia-Geräte...... Ach ja, und freie DOS-Systeme werden auch noch aktiv entwickelt, auch wenn sie in der Nutzung längst marginalisiert sind. Die Aussage umseitig ist nicht ganz richtig, aber eben auch nicht ganz falsch. Ich schlage vor, dass sie sich auf Betriebssysteme beziehen sollte, die noch aktiv (weiter-)entwickelt werden und FAT unterstützen. --H7 ^{(Mid am Nämbercher redn!)} 14:29, 14. Mai 2019 (CEST)