MAGX´ Macken

[mfro]

Könntest Du bitte mal die Quellen-Angabe für die relevante MS-Spezi. etwas genauer machen? Ich habe jetzt eine halbe Stunde lang vergeblich in dem großen Heuhaufen gestochert...

Microsoft FAT32 Spec

[ari.tao]

^^-- Danke.
Und was sagst Du zu den ´hidden sectors´?

[ari.tao]

Microsoft FAT32 Spec

Interessante Lektüre; das meiste ist gut verständlich, ein paar wenige Stellen sind mir noch dunkel. Gibt´s auch etwas ähnliches zu Partitionierungs-Schemata & RootSektor?

Zu den ´hidden sectors´ habe ich leider nur diesen Absatz gefunden:

Code: [Auswählen]

BPB_HiddSec 28 4
Count of hidden sectors preceding the partition that contains this FAT volume.
This field is generally only relevant for media visible on interrupt 0x13. 
This field must always be zero on media that are not partitioned. 
NOTE: Attempting to utilize this field to align the start of data area is incorrect.

[mfro]

Ich könnte mir höchstens vorstellen, daß mit den hidden sectors das Wurzelverzeichnis (das bei FAT32 ja im Datenbereich liegt) versteckt werden sollte (warum auch immer).

Wenn Du dir das Datum der MS-Spezifikation anschaust, kannst Du MagiC wohl auch nicht mehr ernsthaft böse sein. Höchstwahrscheinlich gab's damals noch keine frei verfügbare FAT32 Spezifikation und manches war "nur geraten".

. Warum wird die Plattengeometrie verändert? (255 heads)

Ich denke, das ist höchstens für PC's mit alten BIOSen relevant. Die verwenden u.U. noch die C/H/S Adressierung und die ist in der "Bitbreite" für Cylinder- und Sektoranzahl beschränkt. Für große Platten bleibt da nur, die Anzahl der Heads "virtuell" auf 255 zu erhöhen, um überhaupt halbwegs in die Mitte der Disk zu kommen (daher rührt auch das Limit von 504 MB bei ganz alten bzw. 128 GB bei alten DOSen).

Gibt´s auch etwas ähnliches zu Partitionierungs-Schemata & RootSektor?

Du verwendest doch Atari-Partitionierung, oder? Das steht im Profibuch.

[ari.tao]

^^-- ja, und auch im ´Scheibenkleister´ - ist alles schon sooo lange her... Mich interessierte aktuell eher der Unterschied zum DOSen-Reich.

Daß die Platten-Geometrie zB. für CFs völlig irrelevant ist, das ist trivialerweise klar. Die Frage war eher, warum mkfatfs sie nicht unverändert läßt! (und ebenso die Anzahl der ´hidden sectors´.)

Ich könnte mir höchstens vorstellen, daß mit den hidden sectors das Wurzelverzeichnis (das bei FAT32 ja im Datenbereich liegt) versteckt werden sollte (warum auch immer).

Das erklärt aber nicht die große Zahl, zB. auf der FAT16er ´I:´! (die ganz normal ´gut gefüllt´ ist.)

Wenn Du dir das Datum der MS-Spezifikation anschaust, kannst Du MagiC wohl auch nicht mehr ernsthaft böse sein. Höchstwahrscheinlich gab's damals noch keine frei verfügbare FAT32 Spezifikation und manches war "nur geraten".

Es hilft ja nix, "MAGX böse zu sein". Ich will nur genau wissen, wo der Bug steckt und worin er besteht. Danach kann man entscheiden, ob es ein Fixing gibt und ob sich das lohnt, oder ob ein Workaround ausreicht bzw. welcher zu nehmen ist - wenn es einen gibt. Letztendlich läuft´s auf einen Unterschied zw. Atari und DOSe hinaus, der zu beachten wäre. Ist ja nicht der erste.

[ari.tao]

Vor kurzem habe ich mir große Teile dieses Threads nochmals angeschaut und den Eindruck gewonnen, daß #63 möglicherweise unserem Biest schon nahe auf der Spur war: Da es möglich ist, einen Zählfehler zu provozieren, der zu wenig freien Platz anzeigt, könnte es da nicht auch das andre geben, daß also zu viel davon angezeigt wird? Dann wäre es ja gar kein Wunder, wenn in die Pampa geschrieben wird... Ich habe aber bisher keinen Beleg für diese Hypothese. Darum werde ich mir ibs. den Info-Sektor, der für die Zählerei zuständig ist, mal in den og. FAT-Specs. ansehen.
Leider habe ich aber die nächsten Wochen weder Zeit noch Gelegeheit dazu, also muß ich hier erst einmal pausieren...

[ari.tao]

So, wieder da.
Was zwischendurch geschah:

-)
Ich habe mein Haupt-Plättle (eine CF Sandisk Ultra II 4GB) neu partitioniert (-> Anhang) und gefüllt, eine trotz SektorCopy der ersten 1,75 GB mühsame und einschl. Treechck langwierige Prozedur, und dabei auf die 2GB große F32er Archiv-Partition ´J:´ auch
   mkfatfs -a -f 2 -F 32 -s 2 J:
angewendet, um die Granulation auf 1024B./Cluster zu drücken. Da, wie früher schon bemerkt, mkfatfs einen hohen Speicher-Bedarf hat, ging das nicht auf meinem Falcon (mit 11MB freiem Speicher), sondern nur auf meinem TT (und anschl. Clonen auf das Plättle im Falcon).
Die gute Nachricht: ca. 30MB mehr Platz auf J (nicht gerade üppig - aber immerhin).
Die schlechte Nachricht: Nach Wechsel von MiNT zu MAGX zeigte sich sofort wieder der Zähl-Fehler! Ich werde daher, weil ich wie dargelegt nicht von dessen Harmlosigkeit überzeugt bin, die F32er Parts. unter Magx auch weiterhin nur mit Schreibschutz benutzen.
Bem.1: Kopieren mit MiNTs (1.15.9) GEMDOS auf Parts. ohne LFN hält auch noch besondere Tücken bereit: zB. gehen Umlauts und manche Sonderzeichen, die unter TOS erlaubt sind, verloren und werden durch den Unterstrich ´_´ ersetzt! Wenn Namen von Ordnern betroffen sind, fehlt dann deren gesamter Inhalt! Das ist also ähnlich schlimm, wie beim Transfer zw. Ataris und DOSen. Von einer ordentlichen Kopier-Routine in MiNT würde ich erwarten, daß sie 1 : 1 kopiert!

=)
Ich habe auch
   dosfsck -v J:
auf meinem TT erfolgreich laufen lassen können (derzeit keine Beschwerden mehr). Das ging jedoch nicht mit 27MB, aber dann doch mit 30MB freiem Speicher: Der Speicherbedarf von dosfsck ist also noch wesentlich größer als der von mkfatfs. Eine FAT von J ist ca. 8MB groß.
Bem.2: Auch dosfsck versteht die Umlauts nicht: Die erzeugen Meldungen "bad filename...".
Bem.3: dosfsck schreibt in die Konsole mit UNIX-Zeilenenden! Das ist mit dem VT52.prg von MAGX schlecht lesbar - iGgs. zu MiniWin.prg unter MiNT+NAES.

[Skywalker]

Mal eine Frage:
Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.
Wann kam denn FAT32 hinzu?

[KarlMüller]

Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.
Wann kam denn FAT32 hinzu?

Mit 6.1

[Thorsten Otto]

(führe die Diskussion aus "Re: Quellen von Magic, Magxdesk, u.a." mal hier fort, weil sich das zunächst mal nur auf das FAT32 Problem bezieht)

Hab mal ein bisschen experimentiert. Zunächst mal unter Linux ein Drive-Image angelegt das eine Atari-Partitions-Tabelle und eine einzige FAT32-Partition von 140000 Sektoren a 512 Byte enthält. Das Filesystem angelegt auf Linux mit

Code: [Auswählen]

mkdosfs -a -f 2 -F 32 -s 2 /dev/loop0 140000

(/dev/loop0 dabei so eingerichtet daß es auf den Start der Partition im Image verweist)

Resultat, noch bevor ich irgendwelche Dateien dorthin kopiert habe:

Von MagiC/MAGXDESK:



"Bytes belegt" und "Bytes frei" sind Nonsense, "Bytes gesamt" und Anzahl Cluster stimmt aber.

Von MagiC/Jinnee:



Im Prinzip gleiches Ergebnis, auch wenn für "Bytes free" und "Bytes used" andere Werte angezeigt werden, sind die völliger Blödsinn.

Das gleiche Image, unter Mint & Teradesk:



Hier ist also alles richtig (die 1K benutzt ist wohl von dem Root-Verzeichnis).

Die Anzeige in MagiC wird auch nicht viel besser nachdem ich von MiNT aus Dateien auf die Partitiion kopiert habe, ändert sich aber. Fazit: da scheint wirklich noch was im argen zu sein, und es ist nicht nur ein reiner Anzeige-Fehler der Desktops (die Partition ist nur ~70MB, damit kann ein Überlauf während der Berechnung eigentlich nicht das Problem sein).

[Thorsten Otto]

(führe die Diskussion aus "Re: Quellen von Magic, Magxdesk, u.a." mal hier fort, weil sich das zunächst mal nur auf das FAT32 Problem bezieht)

Hab mal ein bisschen experimentiert. Zunächst mal unter Linux ein Drive-Image angelegt das eine Atari-Partitions-Tabelle und eine einzige FAT32-Partition von 140000 Sektoren a 512 Byte enthält. Das Filesystem angelegt auf Linux mit

Code: [Auswählen]

mkdosfs -a -f 2 -F 32 -s 2 /dev/loop0 140000

(/dev/loop0 dabei so eingerichtet daß es auf den Start der Partition im Image verweist)

Resultat, noch bevor ich irgendwelche Dateien dorthin kopiert habe:

Von MagiC/MAGXDESK:



"Bytes belegt" und "Bytes frei" sind Nonsense, "Bytes gesamt" und Anzahl Cluster stimmt aber.

Von MagiC/Jinnee:



Im Prinzip gleiches Ergebnis, auch wenn für "Bytes free" und "Bytes used" andere Werte angezeigt werden, sind die völliger Blödsinn.

Das gleiche Image, unter Mint & Teradesk:



Hier ist also alles richtig (die 1K benutzt ist wohl von dem Root-Verzeichnis).

Die Anzeige in MagiC wird auch nicht viel besser nachdem ich von MiNT aus Dateien auf die Partitiion kopiert habe, ändert sich aber. Fazit: da scheint wirklich noch was im argen zu sein, und es ist nicht nur ein reiner Anzeige-Fehler der Desktops (die Partition ist nur ~70MB, damit kann ein Überlauf während der Berechnung eigentlich nicht das Problem sein).

[ari.tao]

Will hier doch wenigstens mal dieses interessante ZwischenErgebnis verlinken:
    https://forum.atari-home.de/index.php/topic,14246.msg234419.html#msg234419