Software > Alternative Betriebssysteme

MAGX´ Macken

<< < (10/27) > >>

goetz @ 3rz:

--- Zitat von: mfro am Di 14.02.2017, 08:03:19 ---
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.


--- Ende Zitat ---

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

--- Zitat von: mfro am Di 14.02.2017, 08:03:19 ---
--- Zitat von: ari.tao am Di 14.02.2017, 00:05:49 ---1) Was ist die Ursache der in #17 dargestellten Katastrophen?
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?
--- Ende Zitat ---
Ich bin nicht in der Lage, dir diese beiden Fragen zu beantworten, weil ich kein MagiC habe. Bei mir läuft nur MiNT. ...
--- Ende Zitat ---
und

--- Zitat von: mfro am Di 14.02.2017, 08:03:19 ---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.
--- Ende Zitat ---
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:

--- Zitat von: mfro am Di 14.02.2017, 08:03:19 ---Insofern ist mir unverständlich, warum Du deinen Fehler anscheinend auf der MiNT-Seite suchst.
--- Ende Zitat ---
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

--- Zitat --- Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.
--- Ende Zitat ---
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.

--- Zitat --- 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.
--- Ende Zitat ---
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ß:

--- Zitat von: mfro am Di 14.02.2017, 08:03:19 ---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.
--- Ende Zitat ---
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:

--- Zitat von: 1ST1 am Di 14.02.2017, 07:34:16 ---Momentan stocherst du im Nebel, denn du weißt nicht, ob MagX oder MiNT die korrekten Angaben macht.
--- Ende Zitat ---
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...

--- Zitat von: 1ST1 am Di 14.02.2017, 07:34:16 ---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.
--- Ende Zitat ---
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:

--- Zitat von: ari.tao am Mi 15.02.2017, 03:51:39 ---
--- Zitat --- Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.
--- Ende Zitat ---
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.
--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete