Software > Alternative Betriebssysteme

MAGX´ Macken

<< < (13/27) > >>

ari.tao:
^^-- Um den Text zu ändern, muß man verstehen, was das Ding tut. Und das geht nicht ohne C-Kenntnisse. Mein Ruf nach einer Doku für mkfatfs ist ja bisher ungehört in den Weiten des Alls verklungen.
Was den Respekt betrifft - den haben wir 1968 schlicht abgeschafft (damals war ich mitbeteiligt), ibs. ggü. Leuten, die sich autoritär verhalten.
Und was den auf der Wolke angeht: Nach meinem Gefühl hockt der immer noch im Fegefeuer. Für das , was er bis Version 1.15.9 geleistet hat, bin ich ihm äußerst dankbar (und er war sich sehr bewußt, daß die Doku mangelhaft war), aber das Chaos danach, das er hinterließ, das müssen jetzt wir Erben aufräumen (und nicht noch vergrößern).

IS: Himmel & Hölle sind Topoi im Gedächtnis der Überlebenden.
Huch, das ist ja schon wieder so eine Zwischenbemerkung, extra kleingeschrieben, damit Du sie ignorieren könntest, die Dir vermutlich nicht gefällt.


--- Zitat von: mfro am Fr 17.02.2017, 11:46:08 ---Warum mußt Du's uns eigentlich immer so schwer machen, dich sympathisch zu finden?
--- Ende Zitat ---
Wenn das ein Problem ist, Euer Majestät, dann gibt es imho zwei Möglichkeiten: Entweder, Du entwickelst etwas "sympathy for the devil" >:D, oder aber, Du hörst auf, mich als den Teufel zu sehen, der Dir Deine schöne heile Welt kaputtmacht, und akzeptierst stattdessen, daß ich genau wie hoffentlich auch Du daran arbeite, MiNT zu verbessern :). Ich tue das mit den Möglichkeiten, die ich habe, also Tests und Kritik (die Du als ´meckern´ abqualifizierst) und im Sinne einer arbeitsteiligen Welt könntest Du dann die Patches machen, zu denen ich nicht in der Lage bin. Nimm meine Texte mal ´sportlich´ (die korrekte Übersetzung des engl. Wortes ´Sport´ ist ´Freizeitbeschäftigung´).
Ich weise noch dezent darauf hin, daß es in diesem ganzen Thread darum geht, einen Bug endlich dingfest zu machen, der äußerst schwer zu lokalisieren ist, und ich habe bisher alle meine Kraft dafür aufgeboten; für Eitelkeiten, egal ob eigene oder fremde, fehlt mir manchmal die Energie.


--- Zitat ---    -c     Check filesysten as is gets built 
--- Ende Zitat ---
Kann ich leider nicht als korrektes Englisch erkennen. Das engl. Wort für ´während´ findet sich darin auch nicht. Und zu einer ´Überprüfung´ gehört imho immer zuerst mal die Darstellung dessen, was da vorhanden ist.


--- Zitat --- 
--- Zitat --- ..."XHDI major number 12, XHDI minor number 0".
--- Ende Zitat ---
...Gerätenummer...
--- Ende Zitat ---
Stünde da das Wort ´device´, so hätte sogar ich das erkannt...


--- Zitat von: mfro am Fr 17.02.2017, 11:46:08 --- ...BIOS... (Du erinnerst dich?...).
--- Ende Zitat ---
Nicht ich habe unnötig das BIOS erwähnt, sondern Du (Du erinnerst Dich?)!

Bei diesem hier:

--- Zitat von: mfro am Fr 17.02.2017, 11:46:08 ---
--- Zitat von: ari.tao am Fr 17.02.2017, 07:18:45 ---   ...
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.
--- Ende Zitat ---
ist mir beinahe die Kinnlade heruntergefallen. Es geht da um fast 1,8MB, und Du fängst an, mit ein paar Verwaltungs-Sektoren herumzukrümeln, deren Berücksichtigung die Sache ja nur noch schlimmer machen würde: Schon die 1.845.184 kB sind ja deutlich mehr als die 1.844.000,5 kB, die für die gesamte Part. zur Verfügung stehen. Aber wenn Du meinst, daß ich falsch rechne - warum präsentierst Du nicht mal die nach Deiner Meinung korrekte Rechnung?!

Alles in allem: Könntest Du nicht mal, @mfro , bittebittebitte, nachdem Du Einblick in den QuellCode genommen hast, die längst überfällige Doku für mkfatfs schreiben?
Und ganz doll fände ich es, wenn jmd. an mkfatfs ein Arg. anhängt, um alle Parameter einer Part. auslesen zu können...

1ST1:
Wegen dem Falsch Rechnen habe ich empfohlen, erstmal Windows und dann über die gleiche Partition den Atari drübergucken zu lassen. Vielleicht verrechnen sich ja beide, also mint und magx und die Wahrheit liegt in der Mitte?

ari.tao:
^^-- Wie schon gesagt, es fehlt am nötigen Werkzeug & Knoffhoff.
-------
Inzwischen habe ich drei Tage lang Tests gefahren, hier ein Zwischenbericht. Es gibt ein paar Neuigkeiten, über die man sich vorsichtig freuen kann:
1) Die Differenz beim Part.-Start um einen Sektor ist wohl geklärt. Da sie bei Primär-Partitionen nicht auftritt, sondern nur bei Parts. mit ´extended´-Status, hat das wohl mit der Verwaltung letzterer zu tun, aber überhaupt nix mit den Bootsektoren!
2) Inzwischen habe ich bemerkt, daß mkfatfs immer noch eine Sicherheitsabfrage einschiebt, bevor es ernst macht.
Leider kriegt man dann doch nicht, zB. mit "mkfatfs -f 2 R", den Ist-Zustand dargestellt, sondern bloß die ziemlich willkürlichen Voreinstellungen für die Änderung. Ich habe unten nochmal einen ScreenShot angehängt, der iW. dem aus #27 entspricht, aber diesmal unter MAGX + JINNEE; besonders eindrücklich ist der ´Zählfehler´ von MAGX zu sehen (vgl. ´Bytes frei´, ´Bytes benutzt´ & ´Bytes gesamt´).
Sodann möchte ich einen weiteren Test präsentieren (-> 2. Shot):

C) Eine 500MB-CF-Card (die kleinste in meiner Sammlung), diesmal am IDE-Port des Falcon, habe ich neu eingerichtet mit HDDR. als nur eine TOS-Partition. Da mkfatfs nur F32 oder $0b als Grundlage akzeptiert, habe ich sodann mit HDDR. den Typ auf F32 geändert und danach "mkfatfs -f 2 -F32 -s 4 K:" aufgerufen, wie von @KarlMüller in #31 vorgeschlagen. Danach habe ich die Part. K gefüllt, immer schön abwechselnd einige MB unter MiNT und MAGX. Das ging soweit ohne Probleme (und ibs. ohne Zählfehler), bis nur noch 17MB frei waren. Dann habe ich unter MiNT ca. 20MB wieder gelöscht, so daß nun 37MB frei waren, und zu MAGX gewechselt: Da wurden nach wie vor nur 17MB angezeigt, sowohl von MagxDesk als auch von Jinnee. Ich habe dann wiederum abwechselnd unter MAGX & MiNT weiter K gefüllt, zwischendurch gab´s einen riesigen Zählfehler unter MAGX, aber irgendwann zeigten beide wieder friedlich den kleinen freien Rest an. Der Zählfehler von Magx ist zwar unangenehm, scheint aber nicht wirklich gefährlich zu sein (doch eine Überprüfung mit TreeChk fehlt noch).
Edit.: Tree-Check sagt: Alles ok!

Dieser Test bestätigt also zunächst mal auch Eure Erfahrungen, @Lukas Frank & @Nervengift , daß mkfatfs hilft, das ´Böse 3eck´ zu umgehen. Interessant & etwas irritierend auch, daß HDDRUTIL nach Anwendung von mkfatfs meint, K sei überhaupt nicht mehr partitioniert, aber HDDRIVER tut anstandslos seinen Dienst.
Im Moment sieht´s also so aus, daß HDDRUTIL den ´Schwarzen Peter´ hat.

Noch Ideen für neue Tests?

Zu klären ist immer noch, @mfro , die seltsame Meldung von mkfatfs zur Part.-Größe...

ari.tao:
Nachtrag zu Test C):
Der Zählfehler von MAGX ist doch nicht so total harmlos:
Er kann nämlich mitunter dazu führen, daß bei einem Kopier-Versuch die Meldung kommt "Nicht genug Platz auf ..." obwohl unter MiNT noch genug Platz angezeigt wird und das Kopieren dort auch erfolgreich ist!
Rätselhaft ist auch, wie es zu der beschriebenen ´Selbstheilung´ kommt; kann man sie triggern?

ari.tao:
Ein weiterer Test:
D) Ausschließlich unter MAGX:
Eine 1GB-CF-Card am Falcon-IDE-Port mit HDDRUTIL partitioniert in vier F32-Partitionen a 500.000 Sektoren (also fast 256 MB).
Als erstes fällt auf, daß die Cluster-Größe 8 Sektoren beträgt (-> Anhang). HDDRUTIL führt also nicht die zu erwartende Optimierung durch (ie. bloß ein oder höchstens zwei Sekt./Cluster), wie es das sonst für FAT16 macht. Der Verschnitt bleibt entsprechend groß.
Sodann habe ich alle vier Parts. gefüllt, soweit ohne Probleme und ibs. auch ohne Zählfehler (den ich auf Grund der Größenbeschränkung auch nicht erwartet habe). Dann die letzte Part. teilweise wieder geleert und neu gefüllt, wieder ohne Probs.  Dann die vorletzte Partition ebenso behandelt: Da plötzlich ein Kopier-Fehler #-65 (-> Anhang). Dann habe ich den zuletzt kopierten Ordner wieder gelöscht - aber das ging nur unvollständig, Fehler #-8 (-> Anhang); zwischendurch kam noch die Meldung "Sektor nicht vorhanden".
Also wieder kaputt, diesmal ganz ohne Beteiligung von MiNT.

Hat vielleicht jmd. die Klartext-Liste der Fehler-Nrn.?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete