Software > Alternative Betriebssysteme
MAGX´ Macken
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 >:D. Wußte gar nicht, daß Du deren Anwalt bist... 8)
Ü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.
-------
--- Zitat von: mfro am Mi 15.02.2017, 18:28:46 ---... sondern lieber was Sinnvolles tun.
--- Ende Zitat ---
Prima!
--- Zitat von: mfro am Mi 15.02.2017, 18:28:46 --- ... Screenshot nochmal studiert.
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht ...
--- Ende Zitat ---
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:
--- Zitat von: ari.tao am Do 16.02.2017, 02:30:01 ---
--- Zitat von: mfro am Mi 15.02.2017, 18:28:46 --- ... Screenshot nochmal studiert.
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht ...
--- Ende Zitat ---
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).
--- Ende Zitat ---
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
--- Zitat von: ari.tao am Do 16.02.2017, 02:30:01 ---
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?
--- Ende Zitat ---
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 !
--- Zitat von: mfro am Do 16.02.2017, 07:55:52 ---
* 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 ...
--- Ende Zitat ---
Also, zum mitrechnen (im ScreenShot von #27 für Part. R):
--- Code: --- 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)
--- Ende Code ---
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".
-------
--- Zitat von: mfro am Do 16.02.2017, 07:55:52 ---
* 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
--- Ende Zitat ---
Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs
--- Zitat --- -c Check filesysten as is gets built
--- Ende Zitat ---
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!
-------
--- Zitat von: mfro am Do 16.02.2017, 07:55:52 ---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...
--- Ende Zitat ---
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:
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 ---Danke, @mfro !
--- Zitat von: mfro am Do 16.02.2017, 07:55:52 ---
* 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 ...
--- Ende Zitat ---
Also, zum mitrechnen (im ScreenShot von #27 für Part. R):
--- Code: --- 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)
--- Ende Code ---
Wo also steckt der Fehler?
--- Ende Zitat ---
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.
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 --- Wie berechnet denn THING seinen Wert? Mit den gleichen MiNT-Calls?
--- Ende Zitat ---
Weiß ich nicht. Aber wenn ich THING wäre, würde ich einfach Dfree() aufrufen und sicher keine BIOS-Funktion (Du erinnerst dich?...).
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 ---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".
--- Ende Zitat ---
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.
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 ---
--- Zitat von: mfro am Do 16.02.2017, 07:55:52 ---
* 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
--- Ende Zitat ---
Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs
--- Zitat --- -c Check filesysten as is gets built
--- Ende Zitat ---
hatte ich so interpretiert, daß man sich damit die vorhandenen Werte anzeigen lassen kann; zumindest für manche scheint das ja zuzutreffen.
--- Ende Zitat ---
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?
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 ---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!
--- Ende Zitat ---
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).
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln