Software > Alternative Betriebssysteme

MAGX´ Macken

<< < (8/27) > >>

KarlMüller:

--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Ganz ohne Kapazitäts-Angabe?

--- Ende Zitat ---
Ja, die holt es sich vom Festplattentreiber.


--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Und warum nicht ´-s 8´ anstatt ´-s 4´ ? (Sonst doch höchstens 1GB ?)

--- Ende Zitat ---
Du kannst auch auch 16, 32, 64 oder 128 nehmen. Es war ein Beispiel. Je Größer die Zahl um so mehr Platz wird bei kleinen Dateien verschwendet.


--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Und keine ´Volume ID´ nötig?

--- Ende Zitat ---
Nö.


--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Und der Rechenfehler stört Dich gar nicht?

--- Ende Zitat ---
Nö, weil ich nie nachgerechnet habe und keine Probleme mit beiden BS habe. Vielleicht rechnets ja Du falsch.


--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Möglicherweise macht mkfatfs immer nur eine FAT, und damit funzt es dann?

--- Ende Zitat ---
Deswegen das "-f 2". TOS kommt mit einer FAT nicht zurecht und bevor das Problem auch bei MagiC und FreeMiNT besteht geht man auf die sichere Seite.

Wenn Du dem ganzen nicht traust, dann sind hier die Quellen von mkfatfs.

ari.tao:
^^-- Seufz. Danke für den Link. Gerade dafür brauche ich doch Hilfe - bin doch AnCetadeltet (Aber wer Fragen zu Modula2 hat: Gerne!).
Mein Verdacht ist, daß die zweite FAT von NFFS/mkfatfs nur gefakt wird, um TOS zufriedenzustellen, während HDDRUTIL tatsächlich zwei FATs anlegt. Sollte das der Fall sein, könnte das Unglück genau in dem Moment passieren, wenn die 2. FAT unter MAGX tatsächlich zum Einsatz kommt. Kennt sich niemand damit aus?

--- Zitat von: KarlMüller am Sa 11.02.2017, 17:50:49 ---
--- Zitat von: ari.tao am Fr 10.02.2017, 09:36:25 ---Und der Rechenfehler stört Dich gar nicht?
--- Ende Zitat ---
Nö, weil ich nie nachgerechnet habe und keine Probleme mit beiden BS habe. Vielleicht rechnets ja Du falsch.
--- Ende Zitat ---
Ich habe genausowenig gerechnet wie Du, sondern iW. bloß die Ergebnisse zweier Rechnungen anderer Leute im obigen ScreenShot nebeneinandergelegt. Da ich nicht glaube, daß es sich um einen Fall von mehrwertiger Logik handelt und auch Quantenlogik mir in diesem Fall nicht weiterhilft: Woran könnte es denn liegen, daß zwei sehr ehrwürdige Herrschaften zu so unterschiedlichen Ergebnissen kommen?!
Noch einmal: Welches Werkzeug habt Ihr denn benutzt für die ursprüngliche Partitionierung, und welchen HD-Treiber benutzt ihr? Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden? (Diese Fragen gehen nicht nur an KM!)

Nervengift:

--- Zitat ---Noch einmal: Welches Werkzeug habt Ihr denn benutzt für die ursprüngliche Partitionierung, und welchen HD-Treiber benutzt ihr? Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden?
--- Ende Zitat ---

Zum Partitionieren kann man im Grunde jeden Atari-Festplatten-Treiber nutzen, der entsprechende Tools mitbringt. AHDI, SCSITool, HDDRIVER, CBHD etc.. Will man allerdings nach der Patitionierung eine FAT32 Partition einrichten und betreiben braucht man einen XHDI kompatiblen Festplattentreiber. Da gibt's dann nur zwei Möglichkeiten: HDDRIVER oder den CBHD. Es sei denn man nutzt die Firebee, die schon über einen eingebauten XHDI kompatiblen Festplattentreiber verfügt. EmuTOS hat auch einen eingebauten Festplattentreiber. Ich müsste jetzt aber nachgucken inwiefern der schon XHDI kompatibel ist.

Nervengift:
Gerade nochmal nachgeschaut: EmuTOS hat die XHDI-Unterstützung seit Version 0.9.5 auch fest eingebaut. Sehr schön. 8)

https://sourceforge.net/p/emutos/news/2015/10/emutos-version-095/

ari.tao:
<OffTopic: Kurze Frage vorweg: Gilt das --^^-- nur für EmuTOS im ROM oder ersetzt ein nachgeladenes EmuTOS auch einen zuvor geladenen HD-Treiber?
OT-Ende>
Ansonsten Danke für Deine Mühe @Nervengift ! Abgesehen von FireBee und EmuTOS war mir das aber alles schon bekannt. In Deiner Aufzählung vermisse ich den PPERA-Treiber - kann der kein XHDI? Ich weise darauf hin, das afaik auch der im HDDR. eingebaute Treiber eine Variante des CBHD ist. Tatsächlich scheint es also _unter_TOS_&_Co_ nur einen einzigen Treiber für FAT32 zu geben - wobei offen bleibt, ob die eine oder andere Variante noch fehlerhaft ist. In diesem Zshg. sind auch Deine Bemerkungen oben in #25 sehr interessant, und ich frage mich, wie kompatibel XHDI mit DOS ist und was tatsächlich in MINT & MAGX eingebaut wurde. Wenn Ihr wirklich durch Anwendung von mkfatfs einen Workaround gefunden habt, der die oben nachgewiesene Katastrophe für Euch bislang vermieden hat, so heißt das ja noch nicht, daß da kein Fehler im System steckt. Das dicke Ende könnte noch nachkommen, wenn eine Partition mal fast voll ist... Dagegen ist/war _mein_ Workaround der Schreibschutz unter MAGX.
Im Moment ist der Stand meiner Erkenntnis dieser:
Irgendwo im 3eck MAGX - MINT - HDDR. steckt ein schwerer FAT32-Fehler!
Wo genau, das ist vorläufig immer noch offen.
Ich kann mir aber vorstellen, daß MAGX sich zu DOS kompatibel verhält, 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.
-------
Ich werde - voraussichtlich nicht vor nächster Woche - noch einen weiteren Test starten und mkfatfs anwenden.

PS: Eine These zu falsifizieren ist einfach: Man braucht nur ein einziges Gegen-Bsp.,
       aber die Korrektheit eines Prgs. zu verifizieren, ist bekanntlich eines der größten Probleme der Informatik!

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete