^^-- 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.