Diskussion:File Allocation Table/Archiv

message: 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)
thread_title:  Sonstiges 1 

message: 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)
thread_title:  Sonstiges 2 

message: 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)
thread_title:  FAT16 bis 4GB 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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  hielt diverse Benutzer (nicht nur IPs) nicht von einem Edit ab. :-( --RokerHRO 21:34, 26. Jan 2006 (CET)

text:  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)
replies: text:  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)
thread_title:  MiB vs MB 

message: 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)
thread_title:  FATX 

message: 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)
replies: text: 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)
thread_title:  Wer hats erfunden? 

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

message: 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)
thread_title:  MiB, GiB und TiB 

message: 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)
replies: text: 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)
thread_title:  FAT ist deutlich älter als QDOS 

message: 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)
thread_title:  Vergleichende Übersichtstabelle 

message: 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)
replies: text: 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)
thread_title:  FAT32plus? 

message: "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)
replies: text: 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)
thread_title:  Grenzen 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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 [] 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text:  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)
thread_title:  MiB --> MB 

message: 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)
thread_title:  FAT 12 mit 32 MB und Hinweis auf "FAT 8" 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: @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)
replies: text:  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)
thread_title:  kennt exFAT Dateiendungen mit mehr als 3 Buchstaben? 

message: Ich hab diese DOS-Versionen also bei den unterstützen hinzugefügt. --MrBurns 05:46, 20. Feb. 2009 (CET)
thread_title:  FAT 32 läuft auch unter MS-DOS 7.10 und 8.0 (enthalten in Windows 95b/95c/98 bzw. Me) 

message: 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 ) hochgestellter Text, modifiziert von -- Qhx 14:55, 3. Jul. 2009 (CEST)
replies: text: 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)

text: 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)
thread_title:  Patent 

message: Zum Abschnitt exFAT, Unterabschnitt "Nachteile": Memory Stick ist doch ein proprietäres Format von Sony. --MrBurns 19:31, 25. Sep. 2009 (CEST)
thread_title:  War Memory Stick je als universelles Speicherkartenformat gedacht? 

message: 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)
thread_title:  Fehler im Artikel 

message: 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)
thread_title:  Zweifelhafte Quelle (erledigt) 

message: > 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)
thread_title:  Es ermöglicht das mit Dateien, die den Namen --linux-.--- tragen. 

message: 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)
thread_title:  Max. Partitionsgröße 

message: 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)
thread_title:  FAT stammt von MS und nicht von Tim Patterson 

message: 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)
replies: text: 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)
thread_title:  Was ist „FAT“ ohne Zahlanhang? 

message: .. sind möglich? Der Artikel schweigt scheinbar hierzu. Scheinbar gibt es eine gewisse begrenzung die von der grösser der Dateinamen abhängt .  Bei mir war eben Ende bei ca. 20'000 dateien à  20zeichen pro dateiname. --Itu 04:48, 28. Nov. 2010 (CET)
replies: text: 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)
replies: text: 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)
thread_title:  Wieviele dateien pro Verzeichnis 

message: 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)
thread_title:  FAT 32 Nachteil ohne Beleg 

message: 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)
replies: text: Wie du schon schriebst: Der Verzeichniseintrag wird entsprechend markiert (1. Zeichen des Dateinamens auf 05hex) 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)
thread_title:  Wie funktioniert löschen von dateien? 

message: 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)
thread_title:  exFAT auslagern 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  FAT8 

message: 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)
replies: text: 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)
thread_title: Die bisherigen SDHC- und Memory-Stick-PRO-HG-Duo-Standards stoßen bei 32 GiB an ihre jeweiligen Systemgrenzen.

message: 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)
replies: text: 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)
thread_title:  Beschränkungen des FAT Dateisystems 

message: 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 (215 · 228 = 243 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)
thread_title:  Maximale Größe von FAT32 

message: "Es gibt mehrere moderne DOS-Systeme, die FAT32 nativ unterstützen" Modern = 1996 eingeführt?? Seit ihr noch nicht im 21. Jd angekommen?? 
: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)
thread_title:  "modern"??