MAGX´ Macken

[mfro]

Irgendwie werde ich das Gefühl nicht los, daß Du da was durcheinanderbringst:

... und ich frage mich, wie kompatibel XHDI mit DOS ist ...

Die Antwort ist: gar nicht.

DOS und XHDI sind zwei Paar Stiefel. DOS (damit meinst Du wohl Treiber für FATxx) enthält Dateisystemtreiber. Es weiß, wie eine FAT aussieht und wie man sich daran entlanghangeln muß, um die Cluster zu finden, die gemeinsam einen Datei- oder Verzeichnisinhalt ausmachen. Wie man von der Platte liest oder darauf schreibt, weiß es nicht, dafür muß es das BIOS bemühen.

Das weiß (über den Gerätetreiber), wie man einzelne Sektoren liest oder schreibt, aber wiederum nichts über FAT oder Cluster. Weil das Atari-BIOS nur rudimentäre Festplattenfähigkeiten hat (die meisten TOSe kennen nur den Rootsektor und können den nur lesen) muß der Festplattentreiber als BIOS-Erweiterung nachgeladen werden. Und weil auch (AHDI-kompatible) Festplattentreiber ernsthafte Einschränkungen haben (es kann nur einen geben und der kann auch nur 16 Geräte verwalten, obwohl das BIOS eigentlich 32 kann), wurde eine Erweiterung erfunden und die heißt XHDI.

XHDI Treiber können (außer daß sie den Partitionstyp kennen) mit FAT nichts anfangen, weil sie nur BIOS-Erweiterungen sind und sektorweise lesen und schreiben können (allerdings können sie dem DOS - über den BPB - den Dateisystemtyp und seine Eigenschaften weitermelden, damit jenes weiß, wie es zuzugreifen hat).

[KarlMüller]

Mein Verdacht ist, daß die zweite FAT von NFFS/mkfatfs nur gefakt wird, um TOS zufriedenzustellen,

mkfatfs legt die Anzahl der FATs an, welche Du beim Parameter -f angibst. Da wird nichts gefakt.

Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden?

Kein Ahnung mehr. Kann sein das HDDRIVER dies noch nicht konnte und da habe ich mich nach entsprechenden Alternativen umgeschaut.

Tatsächlich scheint es also _unter_TOS_&_Co_ nur einen einzigen Treiber für FAT32 zu geben

Der Festplattentreiber hat nichts mit dem Dateisystem zutun. Oder warum kann ich mit FreeMiNT auf eine ext2 zugreifen und mit MagiC nicht? Der Festplattentreiber liefert die unterste Schicht beim Zugriff auf Datenträger.

Ich kann mir aber vorstellen, daß MAGX sich zu DOS kompatibel verhält,

Für Dateisystem gibt es Regeln wie es auszusehen hat. Wenn überhaupt kann man Rücksicht auf kaputte Implementierung nehmen.

und ich vermute mal ganz stark, daß US mit dem Hinweis auf die SCSI-Spezifikation jede Kritik an HDDR. zurückweist und den Fehler bei MiNT sieht.

Uwe Seimet wird das Ganze zurückweisen, weil das nichts mit der SCSI-Spezifikation zu tun hat.

[ari.tao]

^^-- Sehr richtig, ´das Ganze´ und ibs. Kritik an HDDRUTIL hat nichts mit der SCSI-Spezi. zu tun, das hast Du richtig erkannt, und so war´s auch gemeint.
-------

Irgendwie werde ich das Gefühl nicht los, daß Du da was durcheinanderbringst:

... und ich frage mich, wie kompatibel XHDI mit DOS ist ...

Die Antwort ist: gar nicht.
DOS und XHDI sind zwei Paar Stiefel. DOS (damit meinst Du wohl Treiber für FATxx) ...

Und ich habe immer wieder das Gefühl, daß Du in meinen Texten nur nach vermeintlichen Fehlern suchst, anstatt Dich nach Kräften konstruktiv um Verständnis derselben zu bemühen. Aus dem Kontext (-> #25) geht doch klar hervor, daß immer das Gesamtpaket gemeint ist (also einschl. der Tools, ibs. HDU), wenn ich ´Treiber´ oder ´HDDR.´ schreibe. Wie wär´s, wenn Du bitte mithelfen könntest, die beiden drängenden offenen Fragen schlüssig zu beantworten:

1) Was ist die Ursache der in #17 dargestellten Katastrophen?
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?

Es wäre zB. schon hilfreich zu wissen, wie die Größe einer FAT festgelegt wird und warum und durch wen. Das sind wirklich Detail-Kenntnisse, die mir fehlen.

Wir sind uns doch hoffentlich darüber einig, daß
a) FAT32 auf dem Atari nur möglich ist mit XHDI >= 1.10;
b) XHDI spezifisch für Atari ist und auf DOSen nicht vorkommt;
c) auch DOSen durchaus FAT32 beherrschen;
d) FAT32 unter MiNT erst möglich ist, seit FN sein NFFS in MiNT_1.15.x erfand;
e) HDDRUTIL das FAT32 vor Vers. 6.23 nicht richtig konnte;
f) MAGX das FAT32 auch erst seit Vers. 6.x kann.
Was also soll das Gerede über das BIOS?! Das BIOS tut hier nichts zur Sache und ist von mir auch nicht erwähnt worden. Nebbich!
-------

Mein Verdacht ist, daß die zweite FAT von NFFS/mkfatfs nur gefakt wird, um TOS zufriedenzustellen,

mkfatfs legt die Anzahl der FATs an, welche Du beim Parameter -f angibst. Da wird nichts gefakt.

Wenn Dir mein Versuch der Erklärung nicht gefällt, dann mach´ doch mal einen eigenen Vorschlag, wie og. 2) aufzulösen ist.

Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden?

Kein Ahnung mehr. Kann sein das HDDRIVER dies noch nicht konnte und da habe ich mich nach entsprechenden Alternativen umgeschaut.

Heißt das, man kann ein beliebiges HDU zur Partitionierung mit FAT16 (sic!) nehmen, aus dem AHDI, dem ICD, dem GEsoft, dem SCSITOOL oder was auch immer, und nach Anwendung von mkfatfs erhält man daraus ein FAT32 ? Denn ich habe ja oben gelernt, daß mkfatfs nur auf eine schon bestehende Partition angewendet werden kann, und ein eigenes Tool, um eine originäre Partitionierung zu erstellen, hat MiNT doch wohl nicht.

PS: HDDRUTIL stellt im Menue ´Tools/Geräte-Check´ die Firmware-Version von IDE-Plättlen leider nur verkürzt dar. Aber zB. SCSITOOL kann sie ganz zeigen.

[1ST1]

Ich glaube nicht, dass die Partitionsmarkierungen irgendwas damit zu tun haben. Du solltest sämtliche Kombinationen mal auf eine "echte FAT32" Partition loslassen. Damit meine ich eine, die von einem Microsoft-Tool angelegt wurde, z.B. auf einer Extra-Platte, auf einem Extra-Medium. Das muss der Maßstab sein. Und du solltest dir aufschreiben, welche Laufwerksangaben dir Win9x oder NT-10 über diese FAT32 Partition sagt. Und zwar am besten im leeren Zustand, und mit einer größeren Anzahl Dateien drauf. Das muss der Maßstab sein, denn MiNT und MagX identisch anzeigen müsste.

Momentan stocherst du im Nebel, denn du weißt nicht, ob MagX oder MiNT die korrekten Angaben macht.

Rein Interesse halber wäre auch mal interessant, was TOS zu einer kleinen Fat32 Partition sagt (also je nach TOS-Version z.B. max 512 MB oder 1 GB groß), theoretisch müsste sogar das gehen, dann halt mit 7+~.3-Dateinamen statt der langen Dateinamen. Denn Fat32 wurde abwärtskompatibel gestaltet, ältere Systeme bekommen dann nur diese Kurznamen zu sehen. Und das dann mal mit DOS/Win, MinT und MagX vergleichen.

Ich glaube erstmal, dein Problem ist ein reines Anzeige-Problem, sprich die Methodik wie der jeweilige Desktop von MagX oder MiNT die Daten der Partition ermittelt bzw. errechnet. Du musst erstmal wissen, ob sich MiNT oder MagX irrt, oder beide. Und das kannst du nicht, ohne eine original von einem Micirosft-Tool angelegten Partition zu analysieren.

[mfro]

Irgendwie werde ich das Gefühl nicht los, daß Du da was durcheinanderbringst:

... und ich frage mich, wie kompatibel XHDI mit DOS ist ...

Die Antwort ist: gar nicht.
DOS und XHDI sind zwei Paar Stiefel. DOS (damit meinst Du wohl Treiber für FATxx) ...

Und ich habe immer wieder das Gefühl, daß Du in meinen Texten nur nach vermeintlichen Fehlern suchst, anstatt Dich nach Kräften konstruktiv um Verständnis derselben zu bemühen.

Vielleicht solltest Du künftig dazuschreiben, welche deiner Fragen Du nicht als Frage verstanden haben willst.

Wenn in einem der BIOS-Teile (XHDI-Treiber) ein Fehler wäre, müsste sich der bei anderen Dateisystemtypen auch zeigen und würde nicht nur bei FAT32 auftreten.

Aus dem Kontext (-> #25) geht doch klar hervor, daß immer das Gesamtpaket gemeint ist (also einschl. der Tools, ibs. HDU), wenn ich ´Treiber´ oder ´HDDR.´ schreibe. Wie wär´s, wenn Du bitte mithelfen könntest, die beiden drängenden offenen Fragen schlüssig zu beantworten:

1) Was ist die Ursache der in #17 dargestellten Katastrophen?
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?

Ich bin nicht in der Lage, dir diese beiden Fragen zu beantworten, weil ich kein MagiC habe. Bei mir läuft nur MiNT. Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen. Dabei ist es egal, ob ich das FAT32-Dateisystem mit mkfatfs.ttp auf dem Atari oder mit mkfs auf dem PC angelegt habe.
Insofern ist mir unverständlich, warum Du deinen Fehler anscheinend auf der MiNT-Seite suchst.

[/color]Es wäre zB. schon hilfreich zu wissen, wie die Größe einer FAT festgelegt wird und warum und durch wen. Das sind wirklich Detail-Kenntnisse, die mir fehlen.

Die nutzbare Größe von FAT-Partitionen, die mit unterschiedlichen Tools auf derselben Partition angelegt wurden, muß nicht unbedingt übereinstimmen.

Trotzdem können beide Partitionen korrekt angelegt sein.

• FAT kann Sektoren im Filesystem reservieren
• die Clustergröße ist variabel
• die Größe der FATs ist davon abhängig: je größer die Cluster sind, desto kleiner die FAT
• die Anzahl der für das Wurzelverzeichnis reservierten Cluster kann variieren

Je nachdem, wer das Dateisystem angelegt hat, kann der nutzbare Datenbereich also mal größer und mal kleiner werden (trotzdem ist beides "richtig"), der Vergleich der Größen ist meiner Ansicht nach da nicht wirklich hilfreich.

Aus deinen Beschreibungen entnehme ich, daß MagiC nicht nur die betroffene Partition, sondern u.U. die gesamte Platte kaputtschreibt. Wenn das passiert, liegt der Fehler m.E. eindeutig dort.

Der FAT32-Treiber merkt nicht, daß seine Clusterberechnungen (aus welchen Gründen auch immer) einen physikalischen Sektor ergeben, der außerhalb der Partitionsgrenzen liegt und schreibt unabgefangen da hin. Ohne das geprüft zu haben, würde ich sogar fast annehmen, daß das *nicht* über den XHDI-Treiber (sondern über das "altmodische" Rwabs()) passiert (weil der nach meiner Erinnerung nur mit logischen Sektornummern arbeitet, das also eigentlich gar nicht kann).

Riecht für mich irgendwie nach einem signed/unsigned Fehler.

[goetz @ 3rz]

Aus deinen Beschreibungen entnehme ich, daß MagiC nicht nur die betroffene Partition, sondern u.U. die gesamte Platte kaputtschreibt. Wenn das passiert, liegt der Fehler m.E. eindeutig dort.

Schuß ins Blaue, aber aus Erfahrung: Hintergrund-DMA an? Und wackelige Hardware? Oder Schweineprogramme aktiv?

[ari.tao]

^^-- Nein, Hintergrund-DMA habe ich noch nie benutzt.
      Nein, kein HW-Problem, sonst müßte das auch mit FAT16 passieren.
        Nein, keine Wildschweine vorhanden, aus gleichem Grund --^^
-------
Zunächst mal vielen Dank für Deinen Beitrag, @mfro , ich anerkenne dessen Länge als guten Willen. Die Frotzelei am Anfang überspringe ich mal, ibs. das BIOS war ja längst abgehakt. Leider hast Du Dir den ScreenShot in #27 und meinen darauf bezüglichen Text nicht sorgfältig angeschaut. Du hättest nämlich sonst merken müssen, daß bei der Frage_2 Deine Kommentare

1) Was ist die Ursache der in #17 dargestellten Katastrophen?
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?

Ich bin nicht in der Lage, dir diese beiden Fragen zu beantworten, weil ich kein MagiC habe. Bei mir läuft nur MiNT. ...

und

Die nutzbare Größe von FAT-Partitionen, die mit unterschiedlichen Tools auf derselben Partition angelegt wurden, muß nicht unbedingt übereinstimmen.
Trotzdem können beide Partitionen korrekt angelegt sein.

völlig daneben sind! Deshalb noch mal gaaanz langsam zum mitmeißeln: Bei der Frage_2 ist erstens MAGX in keinster Weise beteiligt und zweitens habe ich da nicht zwei verschieden angelegte Parts. verglichen, sondern ein und dieselbe Partition R mit drei verschiedenen Werkzeugen betrachtet, nämlich
   alfa) mit dem Part.-Menue von HDDRUTIL (mit dem sie erzeugt wurde)
   beta) mit dem Datei-Info-Menue von THING und
   gama) mit dem MiNT-Tool mkfatfs -c
und ich habe ganz bewußt den ScreenShot unter NAES2+MiNT gemacht (und nicht unter MAGX), damit da gar kein Zweifel möglich ist.
Während nun beta mit alfa zusammenstimmt (obwohl die beiden sonst gar nichts verbindet), widerspricht gama den beiden offensichtlich! Außerdem erscheint es mir völlig absurd anzunehem, daß HDDR. nicht mehr weiß, was es da getan hat. Der Fehler im MiNT-Tool mkfatfs ist also offensichtlich, die weitere Frage ist nur, ob es ein harmloser Darstellungsfehler ist (wie auch schon von dem Zählfehler in MAGX oben behauptet wurde) oder ob er sichtbarer Ausdruck eines ernsten Hintergrunds ist: Erst dann hätte er eine Relevanz in Bezug auf Frage 1 ! Da wären also MiNTzer mal gebeten, genauer hinzuschauen. Ist ja übrigens nicht das erste Mal, daß ich eine Macke in MiNT aufgedeckt habe. Das hier:

Insofern ist mir unverständlich, warum Du deinen Fehler anscheinend auf der MiNT-Seite suchst.

wäre damit wohl auch geklärt, bis auf die Kleinigkeit, daß es sich da nicht um _MEINEN_ Fehler handelt: Genausowenig, wie ich mit fremden Federn geschmückt werden möchte, so möchte ich auch nicht mit fremdem Dreck beworfen werden.
Wenn Du schreibst

Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.

kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe. Aber weder Deine noch meine Erfahrung ist ein Beweis, daß der Fehler bei MAGX liegt, und nicht bei MiNT oder gar HDDR.

Aus deinen Beschreibungen entnehme ich, daß MagiC nicht nur die betroffene Partition, sondern u.U. die gesamte Platte kaputtschreibt. Wenn das passiert, liegt der Fehler m.E. eindeutig dort.

So habe ich ja zunächst auch gedacht (-> Anfang des Threads), aber dann kamt Ihr mir ja mit mkfatfs und dem Argument, daß damit wechselnder Zugriff unter MAGX & MiNT problemlos sei: Das begründet einen Zweifel an dieser These, wie auch die Tatsache, daß bei den oben in #17 referierten Tests nur einmal die ganze Part.-Tabelle, ein andermal aber nur die FAT32-Part. kaputt war.
Ganz zum Schluß:

Der FAT32-Treiber merkt nicht, daß seine Clusterberechnungen (aus welchen Gründen auch immer) einen physikalischen Sektor ergeben, der außerhalb der Partitionsgrenzen liegt und schreibt unabgefangen da hin. Ohne das geprüft zu haben, würde ich sogar fast annehmen, daß das *nicht* über den XHDI-Treiber (sondern über das "altmodische" Rwabs()) passiert (weil der nach meiner Erinnerung nur mit logischen Sektornummern arbeitet, das also eigentlich gar nicht kann).
Riecht für mich irgendwie nach einem signed/unsigned Fehler.

steuerst Du nun doch noch etwas bei, was uns vielleicht der Lösung näher bringt - aber genau da bin ich mit meinem Latein am Ende.

[ari.tao]

Auch Dir vielen Dank für Deine Mühe, @1ST1 ! Du unterliegst zwar einem ähnlichen Irrtum wie mfro:

Momentan stocherst du im Nebel, denn du weißt nicht, ob MagX oder MiNT die korrekten Angaben macht.

indem Du nicht gemerkt hast, daß die Frage_2, die die Korrektheit der von mkfatfs gemachten Angaben in Zweifel zieht, zunächst mal gar nichts mit MAGX zu tun hat (und erst relevant wird für das og. böse 3eck, in dem MAGX involviert ist, wenn sie zuungunsten von MiNT beantwortet werden muß), aber Du steuerst ein paar neue Ideen bei, die ich mal näher betrachten möchte.
Da wäre zunächst mal Deine Meinung, daß FAT32 unter Windows der Maßstab sein muß, an dem sich andere Implementierungen messen lassen müssen. Dem könnte ich zustimmen, wenn ich wüßte, daß MAGX & MiNT (und ibs. NFFS von FN) ihr FAT32 bei Windows ´abgeschaut´ haben. Das weiß ich aber leider nicht, sondern ich nehme eher an, daß es da irgendwo draußen in der weiten Welt eine abstrakte Spezifikation gibt, von der alle drei ihre Weisheit bezogen haben. Aber vielleicht kommt es darauf gar nicht an, weil man sich einfach dem Defakto-Standard beugen muß.
Leider habe ich dann praktische Schwierigkeiten, Deiner Anregung zu folgen: Ich besitze weder Win9x noch NT-10 noch die nötigen Tools noch die Erfahrung, damit umzugehen... Und die Analyse von FAT32-Parts. auf dem Atari ist mir leider auch nicht möglich: Wie oben schon bemerkt, können meine beiden DiskMonitore SED und Diskus leider kein FAT32...

Rein Interesse halber wäre auch mal interessant, was TOS zu einer kleinen Fat32 Partition sagt (also je nach TOS-Version z.B. max 512 MB oder 1 GB groß), theoretisch müsste sogar das gehen, dann halt mit 7+~.3-Dateinamen statt der langen Dateinamen. Denn Fat32 wurde abwärtskompatibel gestaltet, ältere Systeme bekommen dann nur diese Kurznamen zu sehen. Und das dann mal mit DOS/Win, MinT und MagX vergleichen.

Zunächst mal möchte ich klarstellen, daß Langnamen auf dem Atari erstens sowohl unter FAT32 als auch FAT16 eingerichtet werden können und zweitens weder unter Fat16 noch FAT32 eingerichtet sein müssen. Meine FAT32er benutzen _keine_ Langnamen. Ein Dilemma ist höchstens, daß man sie unter Windoof nicht abstellen kann. Desweiteren ist es leider so, daß TOS (sic!) FAT32-Parts. schlicht ignoriert. Dafür braucht man MAGX oder MiNT.
Die Frage, ob ´kleine´ FAT32er nützlich wären, die habe ich mir auch schon gestellt. Die Antwort ist: Damit ließe sich der ´Verschnitt´ deutlich reduzieren, aber TOS (sic!) könnte nicht davon booten. Während ich die Tests in #17 noch mit Clones meines gesamten Plättles machen mußte (um an lang zurückliegende Erfahrungen anknüpfen zu können), habe ich vor, weitere Tests ´mit reduziertem Aufwand´ zu fahren, nämlich kleineren FAT32ern.

[mfro]

Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.

kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.

Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.

[1ST1]

In Windows 95 und später findest du die Referenzimplementierung von FAT32. Alles was sich FAT32 nennt, beruft sich genau auf diese Implementierung. Daher ist das, was Windows 9x und später erzeugen, der Maßstab. Und Microsoft ist auch der Entwickler dieses Dateisystems und hat es auch patentiert. Genau wie das spätere exFAT (wurde mit Windows 7 eingeführt und auf Vista und XP rückportiert, kann mehr als 32 GB Partitionen und Dateien größer als 4 GB).

Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht. Das wurde erst mit FAT32 eingerichtet. Und FAT32 ist abwärtskompatibel zu FAT16, das heißt, eine FAT32-Partition, die die Größenbeschränkung von FAT16 einhält, ist von einem FAT16-System beschreib und lesbar, es sieht nur die langen Dateinamen nicht.

Du solltest dir für weitere Untersuchungen erstmal einen PC mit einem Windows hinstellen, an den du ein Laufwerk anschließen kannst, das du auch an deinem ATARI anschließen kannst. Damit du erstmal einen Maßstab hast, an den du deine weiteren Versuche anlehnen kannst. Solche PCs gibts manchmal schon für geschenkt. Übrigens, auch unter Linux dürfte die Implementierung von FAT32 richtig sein.

[czietz]

Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht.

Leider falsch. Lange Dateinamen wurden nachträglich auch FAT12- und FAT16-Dateisystemen beigebracht. Einfacher Test, wenn Du mir nicht glaubst: Eine Diskette (auch heute noch FAT12-formatiert) erlaubt ebenfalls lange Dateinamen unter Windows. Auch unterstützte die allererste Version von Windows 95 noch gar kein FAT32, aber bereits lange Dateinamen, nämlich auf FAT12- und FAT16-Dateisystemen.

VFAT (Virtual File Allocation Table) ist eine Erweiterung des FAT-Formats zur Verwendung langer Dateinamen, die auf FAT12, FAT16 und seit dessen Einführung im Jahr 1997 auch auf FAT32 angewendet werden kann.

Und FAT32 ist abwärtskompatibel zu FAT16, das heißt, eine FAT32-Partition, die die Größenbeschränkung von FAT16 einhält, ist von einem FAT16-System beschreib und lesbar, es sieht nur die langen Dateinamen nicht.

Auch falsch, FAT32 ist komplett anders und (unabhängig von der Partitionsgröße) natürlich nicht von einem System lesbar, das nur FAT12 und FAT16 beherrscht. Wie sollte das auch gehen, wo sich die Verwaltungsstrukturen vollkommen geändert haben.

Alte DOS-/Windows-Versionen (bis einschließlich Windows 95A, Windows NT bis Version 4.0, MS-DOS bis 6.22, PC DOS bis 2000, DR-DOS bis 7.03) können nicht darauf zugreifen.

[yalsi]

In Windows 95 und später findest du die Referenzimplementierung von FAT32.

FAT32 ist mit dem OEM Release Windows 95 B [4.00.1111 / 4.00.1212 / 4.00.1214 - Service Release 2/2.1] in Windows 95 gekommen. Die Clusternummerierung ist dort 32 Bit breit, was es erlaubt, auch auf grossen Platten kleine Cluster zu erzeugen und damit die Platte effizienter auszunutzen. Aber lange Dateinamen kannte Windows 95 / MSDOS 7 schon von Anfang an, darum ist die Aussage:

Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht. Das wurde erst mit FAT32 eingerichtet.

eben falsch- VFAT ist unabhängig von der Breite der Clusteradressen, Dateinamenlänge und Clustergröße haben nichts miteinander zu tun. Bei VFAT kann ein Dateiname sich über mehr als einen Directory-Eintrag erstrecken. Der 1. Eintrag im Directory bekommt einen auf 8 Zeichen gekürzten Namen mit der Tilde und enthält einen Verweis auf den nächsten Directory-Eintrag mit dem Beginn des langen Namens. Der wiederum verweist auf den Fortsetzungseintrag usw. bis alle Zeichen untergebracht sind.
Das praktische daran ist eben gerade, das diese Erweiterung bei FAT12 und FAT16 genauso klappt wie bei FAT32, denn der Aufbau und die Wortbreite im Directory sind unverändert.
Übrigens brachte auch OS/2 Warp 3 lange Dateinamen für FAT16 mit, realisierte das aber anders: Dort erhält jede Datei einen 8.3 Namen und es gibt einen neuen Dateityp, in dem diw lange Namen abgelegt sind. Die Dateisystem-Software sorgt dann für die Anzeige in OS/2, unter MSDOS sieht man nur die 8.3 Namen.

Gruß- Georg B. aus N,

Quelle ua. http://www.winhistory.de/more/win95.htm#win95b

[Nervengift]

Ich besitze weder Win9x noch NT-10 noch die nötigen Tools noch die Erfahrung, damit umzugehen...

Ich hab auch eine 60 GB Platte im Milan drin, auf der sich nur eine FAT32 Partition befindet. Diese Partition habe ich mit OS 10.10 angelegt (GUID-Patitionsschema, MS DOS Dateisystem womit Apple FAT32 in dem Falle meint). Hintergrund dieser Vorgehensweise war, die Platte mal schnell aus dem Milan rausholen zu können und wieder an einem Mac oder Hacki(ntosh) dranhängen können z. B. über USB, um Daten zu schaufeln. Mit dieser Konstruktion gibt es bei mir weder unter MiNT 1.19.x noch Magic Milan 6.1 Probleme.

Ich hatte auch erst versucht HDDRIVER zum Einrichten der Platte zu nutzen und nur eine FAT32 Partition auf der Platte mit HDDRIVER angelegt, aber damit konnte der Mac nicht umgehen. Ich hatte die Platte nicht gemountet bekommen.

[ari.tao]

Mein Dank geht diesmal an @czietz und @yalsi für die Korrektur der falschen Aussagen von 1ST1. Damit ist auch dessen Rat obsolet, daß ich mich nun auch noch mit historischem WinDoof beschäftigen soll.
Die einzige WinDose in meinem Haushalt ist dieser SchleppTop von ASUS hier, auf dem ich diesen Text schreibe und mich, mühsam 1000 Flüche unterdrückend, immer wieder vertippe, ua. wg. dieser absolut unglücklich windoofmäßig positionierten CapsLock-Taste.
Mit dieser meiner SUSA kann ich SD- & CF-Plättle nur als ´Wechselmedien´ nutzen, mit all den Implikationen, die wir anderswo schon besprochen haben.

-------

Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.

kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.

Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.

Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!

Am Ende Deines Beitrags #44 hast Du besseres gebracht. Ich habe mich natürlich auch gefragt, was denn genau in den Tests in #17 kaputt geschrieben wurde. Anscheinend ist in A) der RootSektor (= phys.Sektor 0) überschrieben worden (oder wo sonst steht die Part.-Tabelle?), und in B) möglicherweise der BootSektor (= log.Sektor 0 ?) der Part. R (oder auch bloß deren Root-Directory?) - und das, obwohl bei mir in HDDRIVER der Schreibschutz für _alle_ Root- & Boot-Sektoren immer eingeschaltet ist! Auch HDDR. ist als einer der drei Hauptverdächtigen noch nicht entlastet, genauso wenig wie MAGX und MiNT. Dazu kommt noch, daß nmE. der Crash von A) unter MAGX, der von B) aber unter MiNT passierte. (Bem.: Die Füllung von R geschah immer mit den ´Bordmitteln´ des jeweiligen Desktops, die ja auf das darunterliegende BS rekurrieren, nicht etwa mit der ´GEMDOS-Option´ des KOBOLDs.)

-------

Danke auch für Deinen Beitrag, @Nervengift !

Ich hatte auch erst versucht HDDRIVER zum Einrichten der Platte zu nutzen und nur eine FAT32 Partition auf der Platte mit HDDRIVER angelegt, aber damit konnte der Mac nicht umgehen. Ich hatte die Platte nicht gemountet bekommen.

Weiß US davon?
-------
Hat schon mal jmd. den Treiber (samt Tools) von PPERA für FAT32 benutzt?
-------
PS: Es wäre auch denkbar, daß es sich beim ´Bösen 3eck´ um ein ´Trilemma´ handelt. Damit meine ich: Je zwei beliebige der drei Beteiligten harmonieren gut miteinander - erst der jeweils Dritte stört die Eintracht!

[mfro]

...

Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.

kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.

Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.

Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!

Sowas liegt mir fern.

Ich möchte jetzt mit dir aber nicht über das Zitat streiten (das man m.E. nicht anders interpretieren kann), sondern lieber was Sinnvolles tun. Deshalb habe ich - wie von dir vorgeschlagen - deinen Screenshot nochmal studiert.

Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht (ich nehme an, das ist, was Du uns damit zeigen wolltest?).

Lustigerweise ist es so, daß mkfatfs lediglich XHInqDev2() aufruft und den Rückgabeparameter für den Dateisystembeginn unverändert anzeigt. *Beide* Informationen stammen also letztendlich direkt und ungeschminkt von HDDRIVER (der sich ja bei MiNT als für das Dateisystem zuständig angemeldet hat).

Ich gehe schlicht davon aus, daß das so richtig und gewollt ist und habe mich beim ersten Betrachten auch gar nicht gewundert. XHDI zählt den Bootsektor nicht zum Dateisystem, also startet das gefälligst einen Sektor später. Einen Fehler kann ich da nicht erkennen. Oder hat es mit dem Screenshot eine andere Bewandtnis?

[1ST1]

Wer viel macht, macht auch mal Fehler... Mag sein, dass ich mich bei langen Dateinamen und dem Zusammenhang mit Fat32 getäuscht habe. Das ändert aber nichts daran, dass Windows weiterhin die Referenz ist, damit angelegte Fat32-Partitionen und die zugehörigen Laufwerksinformationen sind das Maß der Dinge. Daran müssen sich alle anderen Implementierungen orientieren und bei Korrektheit das selbe Ergebnis liefern. Linux und MacOS traue ich das auf jeden Fall zu, bei MiNT habe ich auch recht hohes Vertrauen, dass da evtl. vorhandene Fehler durch das OpenSource-Prinzip längst ausgeräumt sind. Bleibt MagX als Closed-Source, die schon seit vielen Jahren nicht mehr verändert wurde.

Deswegen bleibe ich bei meiner Empfehlung. Fat32-Partition mit Windows anlegen und dessen Angaben mit MiNT und MagX vergleichen. SOnst weißt du nicht woran du bist.

Um es mal bildlich auszudrücken: Wenn ich dir einen Zollstock in die Hand drücke, wo der Zentimeter nur 9mm lang ist, dennoch aber 10 Einteilungen hat, kannst du auch nichts mehr korrekt messen. Und du merkst es nicht, weil du den systematischen Fehler nicht bemerkt hast. Also, überprüfe erstmal den Zollstock.

Über deine abfällige Bemerkung sehe ich hinweg.

[ari.tao]

^^-- Was meinst Du bloß?
Ach ja, die Bemerkung über die fatale Position der CapsLock-Taste war ja tatsächlich abfällig ggü. der Fa. KleinWeich  . Wußte gar nicht, daß Du deren Anwalt bist... 
Über Deinen reich bebilderten Ausflug in die Meßtheorie sehe ich mal hinweg  ; bin nämlich Physiker, ua.

Du weigerst Dich anscheinend beharrlich, zur Kenntnis zu nehmen, daß es bei Frage_2 genau darum geht, welchen ´Angaben´ man trauen kann. Noch einmal gaaanz deutlich: Frage_2 hat mit MAGX zunächst mal gar nichts zu tun, und mit Win9x auch nicht. XHDI ist spezifisch für unsere Ataris. Es geht darum, einen verläßlichen ´Zollstock´ auf dem Atari zu finden, um damit dann - vielleicht - Frage_1 aufzuklären. Mein Vertrauen in die Heilkräfte von ´open source´ hat gelitten, seit ich die ´Angaben´ von mkfatfs gesehen habe. Und auf ´ner Dose kann ich anscheinend von HDDR. erstellte FAT32er nicht ´messen´ (meine SUSA will die immer neu einrichten - aber vielleicht mache ich ja ´was falsch). Das umgekehrte, also Win-FAT32er in den Yamaha am Falcon zu füttern, habe ich ja schon avisiert (für nächste Woche) - aber was ist dort der verläßliche ´Zollstock´? mkfatfs? HDDRUTIL?
Du hast doch auch einen Falcon und eine WinDose, und außerdem viel mehr Erfahrung als ich, wie man mit letzterer umgeht - warum machst _Du_ nicht mal den von Dir vorgeschlagenen Versuch und dokumentierst ihn, anstatt immer nur in die Tasten zu labern?!

IS: Es gibt nix gutes - außer man tut es.

-------

... sondern lieber was Sinnvolles tun.

Prima!

... Screenshot nochmal studiert.
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht  ...

Ja, das war für mich eine von drei Auffälligkeiten, wie in #27 beschrieben. (Die anderen beiden sind die Größenberechnung und das fehlende Label). Wenn sich da, wg. der Differenz um einen Sektor, irgendwo mal jmd. um 1 vertan hat: Könnte das dann zur Löschung von Root- oder Boot-Sektoren führen? Das wäre immerhin eine plausible Erklärung, warum der Schreibschutz derselben nicht gegriffen hat!

Könnte es sein, daß MAGX die Daten zur Beschleunigung seiner DateiInfo-Menues direkt hinter den Bootsektor schreibt? Und MiNT dergleichen ganz unterläßt? Und HDDR. den Unterschied nicht (er)kennt?
Das sind Fragen zum FAT32-FS !

[mfro]

... Screenshot nochmal studiert.
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht  ...

Ja, das war für mich eine von drei Auffälligkeiten, wie in #27 beschrieben. (Die anderen beiden sind die Größenberechnung und das fehlende Label).

Die beiden anderen "Auffälligkeiten" lassen sich durch einen Blick in die Quellen leicht klären:

• mkfatfs macht an der Stelle keine "Größenberechnung". Die angezeigten Werte sind 1:1 die, die XHInqDev2() bzw. XHInqTarget2() (also HDDRIVER) zurückliefert. Die können gar nicht falsch sein, sonst (Du erinnerst dich an die "unnötige" BIOS <-> GEMDOS Diskussion?) hättest Du mit anderen Dateisystemtypen ähnliche Probleme.
  
• das "fehlende Volume Label" fehlt schlicht deswegen, weil Du keins (-n) angegeben hast. mkfatfs geht davon aus, daß Du auf einer leeren Partition ein FAT-Filesystem anlegen willst und macht keinen Versuch, aus einem evt. bereits vorhandenen Filesystem irgendwas auszulesen

 Wenn sich da, wg. der Differenz um einen Sektor, irgendwo mal jmd. um 1 vertan hat: Könnte das dann zur Löschung von Root- oder Boot-Sektoren führen? Das wäre immerhin eine plausible Erklärung, warum der Schreibschutz derselben nicht gegriffen hat!
...
Könnte es sein, daß MAGX die Daten zur Beschleunigung seiner DateiInfo-Menues direkt hinter den Bootsektor schreibt? Und MiNT dergleichen ganz unterläßt? Und HDDR. den Unterschied nicht (er)kennt?

Das ist tatsächlich so - allerdings nicht so willkürlich wie Du das beschreibst, sondern als wesentlicher Bestandteil von FAT32. Es definiert im Bootsektor einen Verweis auf einen weiteren (FSINFO) Sektor (der irgendwo liegen kann, tatsächlich aber als nächstes nach dem Bootsektor-Backup angelegt wird), wo die Anzahl der freien Cluster und der zuletzt vergebene Cluster gespeichert wird. Das wird gemacht, um bei der Suche nach Freiplatz bzw. nach dem nächsten freien Cluster nicht jedes Mal die gesamte FAT "abklappern" zu müssen. Dort kann jeweils auch eine -1 als "weiß nicht" stehen.
Soweit ich sehen kann, macht MiNT (in seinem FAT32-Treiber *und* in mkfatfs) das richtig und hat auch einen gewissen Schutz gegen "falsche" FSINFO-Informationen indem es die Werte (und die FSINFO-Signatur) wenigstens insoweit prüft, als daß das gültige Clusternummern sein müssen (und die Signatur stimmt). Stellt es dort eine Diskrepanz fest, rechnet MiNT neu.

Und da sind wir wahrscheinlich beim Kern des Problems (das auch erklärt, warum die Platte kaputtgeschrieben wird, obwohl Du nur davon liest). Es dürfte wohl so sein, daß MagiC beim Zurückschreiben des FSINFO-Sektors einfach an die falsche Stelle schreibt...

[ari.tao]

Danke, @mfro !

• mkfatfs macht an der Stelle keine "Größenberechnung". Die angezeigten Werte sind 1:1 die, die XHInqDev2() bzw. XHInqTarget2() (also HDDRIVER) zurückliefert. Die können gar nicht falsch sein ...

Also, zum mitrechnen (im ScreenShot von #27 für Part. R):

Code: [Auswählen]

   1) mkfatfs zeigt an:
         2 FATs a                      1.799 kb
                                       1.799 kb
         Number of Cluster ...     1.842.184 kb
                                  -------------
      macht zusammen:              1.845.782 kb

   2) HDDRUTIL hat eingerichtet:   7.618.008
                                 - 3.930.007
                                 ----------------------
                                   3.688.001   Sektoren
                                 = 1.844.000,5 kb

   3) THING zeigt an:              1.840.388 kB

        (hat also offensichtlich davon 2 FATs abgezogen)  Wo also steckt der Fehler?
   In den MiNT-Calls XHInqDev2 / XHInqTarget2 oder im HDDRIVER ?
   Wenn er im HDDRIVER steckt, kann er dann nach Anwendung von mkfatfs verschwinden?
   Wie berechnet denn THING seinen Wert? Mit den gleichen MiNT-Calls?

-------

Ich habe da im og. SreenShot noch eine weitere ´Auffälligkeit´ entdeckt, die mir bisher entgangen war:
Das Info von mkfatfs (oben links) behauptet "Found XHDI level 1.25",
aber nach Aufruf von mkfatfs.ttp R -c heißt es: "XHDI major number 12, XHDI minor number 0".

-------

• das "fehlende Volume Label" fehlt schlicht deswegen, weil Du keins (-n) angegeben hast. mkfatfs geht davon aus, daß Du auf einer leeren Partition ein FAT-Filesystem anlegen willst und macht keinen Versuch, aus einem evt. bereits vorhandenen Filesystem irgendwas auszulesen

Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs

   -c     Check filesysten as is gets built

hatte ich so interpretiert, daß man sich damit die vorhandenen Werte anzeigen lassen kann; zumindest für manche scheint das ja zuzutreffen.

IS: Wie soll man darauf vertrauen, daß ein Progr´er eine P.-Sprache beherrscht, wenn er das noch nicht einmal für einfache Fälle der Grammatik der Umgangssprache schafft!

-------

Das ...
     ...
 ... rechnet MiNT neu.
Und da sind wir wahrscheinlich beim Kern des Problems (das auch erklärt, warum die Platte kaputtgeschrieben wird, obwohl Du nur davon liest). Es dürfte wohl so sein, daß MagiC beim Zurückschreiben des FSINFO-Sektors einfach an die falsche Stelle schreibt...

Wie schon gesagt, Test A) hat unter MAGX gecrasht, aber Test B) unter MiNT. Ansonsten war ich mit meiner Analyse ja schon vor ein paar Jahren gerade so weit gekommen wie Du jetzt, ungefähr mit den gleichen Überlegungen, und hatte daraus eben die Konsequenz gezogen, meine FAT32er unter MAGX schreibzuschützen, und deshalb auch die in #1 zitierte Warnung ausgesprochen. Aber darüber sind wir ja nun schon hinaus, im negativen Sinne mit B) und vielleicht im positiven Sinne mit mkfatfs.

[mfro]

Danke, @mfro !

• mkfatfs macht an der Stelle keine "Größenberechnung". Die angezeigten Werte sind 1:1 die, die XHInqDev2() bzw. XHInqTarget2() (also HDDRIVER) zurückliefert. Die können gar nicht falsch sein ...

Also, zum mitrechnen (im ScreenShot von #27 für Part. R):

Code: [Auswählen]

   1) mkfatfs zeigt an:
         2 FATs a                      1.799 kb
                                       1.799 kb
         Number of Cluster ...     1.842.184 kb
                                  -------------
      macht zusammen:              1.845.782 kb

   2) HDDRUTIL hat eingerichtet:   7.618.008
                                 - 3.930.007
                                 ----------------------
                                   3.688.001   Sektoren
                                 = 1.844.000,5 kb

   3) THING zeigt an:              1.840.388 kB

        (hat also offensichtlich davon 2 FATs abgezogen)  Wo also steckt der Fehler?

in deiner Rechnung.

Du hast die reservierten und die versteckten Sektoren nicht berücksichtigt. Ebenso fehlt die für's Wurzelverzeichnis (auch wenn's leer ist) auf einem FAT32-Dateisystem auf jeden Fall bereits belegte Cluster Chain. Daß (nach Abzug von Bootsektor, reservierten und versteckten Sektoren und FATs) der Rest an Sektoren nur insofern verwendet werden kann, als daß er ganzzahlig durch die Clustergröße teilbar sein muß (eine FAT kan schließlich keine "halben Cluster" addressieren) fehlt ebenso.

   Wie berechnet denn THING seinen Wert? Mit den gleichen MiNT-Calls?

Weiß ich nicht. Aber wenn ich THING wäre, würde ich einfach Dfree() aufrufen und sicher keine BIOS-Funktion (Du erinnerst dich?...).

Ich habe da im og. SreenShot noch eine weitere ´Auffälligkeit´ entdeckt, die mir bisher entgangen war:
Das Info von mkfatfs (oben links) behauptet "Found XHDI level 1.25",
aber nach Aufruf von mkfatfs.ttp R -c heißt es: "XHDI major number 12, XHDI minor number 0".

Da solltest Du nochmal drüber nachdenken. Ich finde es nicht besonders auffällig, daß die XHDI Versionsnummer nicht mit der angesprochenen XHDI-Gerätenummer übereinstimmt.

• das "fehlende Volume Label" fehlt schlicht deswegen, weil Du keins (-n) angegeben hast. mkfatfs geht davon aus, daß Du auf einer leeren Partition ein FAT-Filesystem anlegen willst und macht keinen Versuch, aus einem evt. bereits vorhandenen Filesystem irgendwas auszulesen

Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs

   -c     Check filesysten as is gets built

hatte ich so interpretiert, daß man sich damit die vorhandenen Werte anzeigen lassen kann; zumindest für manche scheint das ja zuzutreffen.

Ich verstehe diesen (meiner Ansicht nach völlig korrekten) englischen Satz als "überprüfe Dateisystem während der Erstellung". Was kann man daran als "zeige mir vorhandene Werte" interpretieren?

IS: Wie soll man darauf vertrauen, daß ein Progr´er eine P.-Sprache beherrscht, wenn er das noch nicht einmal für einfache Fälle der Grammatik der Umgangssprache schafft!

Warum mußt Du's uns eigentlich immer so schwer machen, dich sympathisch zu finden?

Abgesehen davon, daß es diesen speziellen Programmierer wahrscheinlich nicht mehr interessiert, weil er sich den Quatsch schon seit einigen Jahren von seiner Wolke aus anschaut: vielleicht denkst Du mal drüber nach, daß Du ohne ihn wahrscheinlich heute kein FreeMiNT hättest, über das Du meckern könntest. MiNT wurde und wird von Leuten in ihrer Freizeit unentgeltlich programmiert. Die Motivation dieser Leute steigert man nicht durch respektlose Bemerkungen über ihre Englisch- oder Programmierkenntnisse, sondern besser über brauchbare Bug-Reports oder gar eigene Patches (um einen Text in mkfatfs zu ändern oder zu verbessern, braucht man keine C-Kenntnisse).