Software > Alternative Betriebssysteme

MAGX´ Macken

<< < (26/27) > >>

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:

--- Zitat von: Skywalker am Di 09.05.2017, 15:44:26 ---Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.
Wann kam denn FAT32 hinzu?

--- Ende Zitat ---
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: ---mkdosfs -a -f 2 -F 32 -s 2 /dev/loop0 140000

--- Ende Code ---

(/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).

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete