MAGX´ Macken

[1ST1]

Oh, falsch verstanden, ich dachte es geht um eine Fat32 Partition.

[ari.tao]

Ja doch, FAT32, erstellt unter GEM von HDDRIVER.
Aber vielleicht sollte ich wirklich mal ein Windows-Plättle zum Test verwenden?
Wenn´s dann ginge, wüßte ich zwar immer noch nicht, warum das obige nicht funzt.
Wenn´s nicht ginge, wär´s sogar noch schlimmer...

[tuxie]

Nur eine Frage am Rande.... den F32 Flag hast du in der mint.cnf gesetzt für dieses Laufwerk ?

[ari.tao]

^^-- huh? Ein ´F32-Flag´ in MiNT gibt´s afaik nicht. Oder meinst Du etwa die Anmeldung per `NEWFATFS=´? Die ist selbstverständlich drin, sowohl für 1.15.9 (drittletzter ScreenShot) als auch für 1.19.cur (vorletzter Shot).
Im übrigen habe ich ja dargelegt, daß F32 unter MINT problemlos funzt, solange nicht mit MAGX ebenfalls darauf geschrieben wird (wobei auch die Anzeige mit dem Menue ´Datei/Informationen...´ anscheinend bereits einen Schreibvorgang auslöst, wenn kein Schreibschutz besteht!). `Nur lesen´ geht auch unter MAGX problemlos.
Den Fall vice versa habe ich aber nicht ausprobiert.

[Lukas Frank]

Was ist denn wenn du die FAT32 Partition nicht nicht HDDriver sondern mit mkfatfs.ttp unter MiNT einrichtest ?

[Nervengift]

Auf dem Milan habe ich eine F32-Partition auf der SSD, die ich mit MiNT erstellt hatte (mkfatfs.ttp) und eine 60 GB Festplatte ist im Milan, die ich mit OS X (10.10) auf F32 initialisiert hatte (GUID-Partitionstabelle, mit der DOS-Partitionstabelle kommt HDDRIVER 9 nicht klar. Das gibt dann Crashes unter MiNT 1.19). Beide F32-Partitionen machen keine Probleme. Weder mit MagiC noch mit MiNT. Lesen und Schreiben ist kein Problem mit MagiC und MiNT. MagiC hat nur eben diesen Zählbug. Ich nutze MagiC Milan 6.1, HDDRIVER 9.7 und MiNT 1.19. Mit HDDRIVER habe ich noch keinen F32-Partition angelegt, weil es da einen Bug gibt in HDDRIVER, was F32 angeht. Aber ich meine, in neueren Versionen ist der abgestellt worden.

[KarlMüller]

Was ist denn wenn du die FAT32 Partition nicht nicht HDDriver sondern mit mkfatfs.ttp unter MiNT einrichtest ?

Das war nach dem was geschrieben wurde auch mein Gedanke. Meine FAT32 sind unter MagiC mit mkfatfs erstellt worden.

[ari.tao]

Danke Euch dreien für den Hinweis auf mkfat32.ttp !
Ich besitze drei Varianten davon verschiedener Größe (die sich aber alle drei mit der gleichen Versions-Nr 0.26 und dem gleichen Datum 2002-09-19 melden), aber ich habe das nie benutzt, wohl weil mir eine hinreichende Beschreibung fehlt. Startet man das Teil ohne Argumente, wird wie bei Unix-Tools üblich eine Liste der möglichen Argumente angezeigt, die ich aber nur teilweise verstehe. Ich habe erraten, daß man als erstes Arg. eine Part.-Kennung angeben muß und habe die jüngste Variante (aus 1.19.cur) mal mit dem Arg. -c auf zwei meiner Parts. losgelassen. Das Ergebnis seht Ihr im unten angehängten ScreenShot.
Zunächst fällt auf, daß mkfat32 die Label nicht findet, die aber von Thing problemlos angezeigt werden. Sodann rechnet man leicht nach, daß Thing den Platz auf der 32er Part. korrekt angibt, aber mkfat32 nicht: Obwohl zwei FATs vorhanden sind, wird nur der Platzbedarf für eine FAT berücksichtigt. Dieser Befund hat mein Vertrauen in mkfat32 schon ziemlich zerstört. Aber damit nicht genug: Der Partitions-Start weicht immer um einen Sektor von dem ab, was mit HDDRIVER angelegt wurde! Wenn MINT und/oder MAGX genauso vorgehen, könnte da schon die Ursache des Desasters liegen!
Leider sind meine DiskMonitore (SED & DISKUS) beide für FAT32 ungeeignet (zeigen nicht einmal die Root-Dirs. an).
Bevor ich nun einen weiteren aufwendigen Test mache, möchte ich gern mal Eure Meinung zu dem oben dargelegten einholen.
Außerdem wäre es nett, wenn sich eine ausführliche Beschreibung für die Args. von mkfat32 fände. Wie habt Ihr denn die FAT32 damit eingerichtet/initialisiert?

Edit.: Dreckfuhler:
Lies ´mkfatfs´ anstatt ´mkfat32´.
Edit.: Das Datum im ScreenShot o.Re. ist falsch, muß natürlich heißen 5.2.2017; der Kalender war versehentlich verstellt.

Edit.: Hier noch die beiden Textstellen, die ich schon weiter oben angeführt hatte:

  Extrakt aus dem LIESMICH des HDDRIVER 8.45
____________________________________________

- Fehler in HDDRUTIL behoben, der bei FAT32-Partitionen zu einer um einen
  Sektor zu kleinen FAT fhren konnte. MagiC-Anwendern wird empfohlen, FAT32
  Partitionen neu anzulegen. MiNT erkennt das Problem automatisch und meldet
  einen Fehler. Wird nichts gemeldet ist die FAT-Gr”že korrekt. (8.23)   

Extrakt aus MAGX' History 6.2
_____________________________

29.1.2000
---------
- Fehler im FAT32-Dateisystem beseitigt. Dfree() lieferte einen falschen
  Wert fr die Anzahl der freien Cluster, nachdem das Medium mindestens
  einmal gewechselt wurde.

20.2.2000
---------
- Der FSINFO-Sektor bei FAT32-Dateisystemen wird jetzt (hoffentlich)
  korrekt behandelt. Das ™ffnen eines seit dem letzten Bootvorgang
  nicht verwendeten FAT32-Laufwerks sollte jetzt deutlich schneller
  gehen.
  Die Daten im FSINFO-Sektor werden jedoch nur angefažt, wenn
  tats„chlich Schreibvorg„nge durchgefhrt werden. Wird ein Laufwerk
  nur lesend verwendet, werden auch ungltige Eintr„ge im FSINFO-
  Sektor nicht gltig gemacht, das erste ™ffnen nach dem n„chsten
  Booten wird daher wieder langsam sein (da der freie Plattenplatz
  durch Durchsuchen der gesamten FAT ermittelt wird). 

[ari.tao]

^^-- Der Anhang oben war endlich möglich.

[Lukas Frank]

Wenn mkfatfs genau so funktioniert wie das ext2 Gegenstück als Parameter einfach das Laufwerk angeben z.B. "D:" ...

->   http://wiki.sparemint.org/index.php/Mkfatfs

[ari.tao]

^^-- So weit war ich ja schon, sogar etwas weiter, nämlich bei Version 0.26 vom 19.09.2002 (die SpareMint-Seite ist offensichtlich veraltet).
Aber was muß/darf ich für die Args. angeben (zB. die ´Volume ID´)?
Und was ist mit den Ungereimtheiten von mkfatfs, die ich gerade geschildert habe? Ignorieren? Das kann doch nicht gutgehen, wenn zwei FATs vereinbart werden, aber nur eine wird bei der Kapazitätsberechnung berücksichtigt? Oder ist die Größe einer FAT nur halb so groß und Thing und HDDRIVER machen was falsch?
Was ist diese ominöse ´Expert Option´?

PS: Der Aufruf funktioniert offenbar nicht wie bei ext2, sondern ohne den Doppelpunkt hinter der Part.Kennung.
Edit.: Aufgerufen habe ich mkfatfs.ttp R -c und mkfatfs.ttp Q -c

[KarlMüller]

Aber was muß/darf ich für die Args. angeben (zB. die ´Volume ID´)?

mkfatfs -f 2 -F 32 -s 4 <Laufwerksbuchstabe>:

[ari.tao]

^^-- ? ? ?
Ganz ohne Kapazitäts-Angabe? Heißt das, man kann mkfatfs nur auf schon bestehende Parts. loslassen?
Und warum nicht ´-s 8´ anstatt ´-s 4´ ? (Sonst doch höchstens 1GB ?)
Und keine ´Volume ID´ nötig?
Und der Rechenfehler stört Dich gar nicht?
Könntest Du Deine Fat32er mal mit dem Part.Menue von HDDU (oder anderem HDU) anschauen? Möglicherweise macht mkfatfs immer nur eine FAT, und damit funzt es dann? Was bekommst Du als Antwort auf das Arg, ´-c´ ?

Ich würde ja Deinen Vorschlag einfach mal ausprobieren - wenn nicht jeder zerstörte Clon so viel Mühe machte, ihn wiederherzustellen. Deshalb lieber erst mal so viele Fragen wie möglich vorab klären!

[Nervengift]

Ganz ohne Kapazitäts-Angabe? Heißt das, man kann mkfatfs nur auf schon bestehende Parts. loslassen?

Ja! Vorher mit einem entsprechenden Programm partitionieren und mit einer entsprechenden Kennung am besten versehen (F32) und dann mkfatfs drauf loslassen. Hat bei mir bislang immer prima geklappt.

[ari.tao]

Wie hast Du denn die Partitionierung vor Anwendung von mkfatfs gemacht? Und mit welchem Tool?

[KarlMüller]

Ganz ohne Kapazitäts-Angabe?

Ja, die holt es sich vom Festplattentreiber.

Und warum nicht ´-s 8´ anstatt ´-s 4´ ? (Sonst doch höchstens 1GB ?)

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.

Und keine ´Volume ID´ nötig?

Nö.

Und der Rechenfehler stört Dich gar nicht?

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

Möglicherweise macht mkfatfs immer nur eine FAT, und damit funzt es dann?

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?

Und der Rechenfehler stört Dich gar nicht?

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

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]

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?

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.

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!