MAGX_6.xx hat die Treiber für F32 schon an Bord, also kann man davon auch booten. Jedoch darf man wg. eines Bugs damit nur lesen, nicht schreiben! Auch nicht mit einem BootSelektor! Am besten sofort schreibschützen!Was ist das denn für ein Fehler? Ich habe die 6.20 im Einsatz und nutze eine Partition mit FAT32 und kann bis jetzt keine Fehler sehen.
-^^- Meine Erfahrung war:
Immer, wenn ich mir eine frisch unter MiNT eingerichtete & befüllte F32 (~1,8 GB) unter MAGX_6.2 auch nur angeschaut habe ohne Schreibschutz (mit dem Menue-Punkt "Informationen..."), dann war sie direkt anschließend nach Rückkehr zu MiNT kaputt!
MagiC hat da einen bekannten Fehler, daß der Zähler des freien Platzes nicht richtig gesetzt wird, aber das ist mehr kosmetischer Natur. Ich betreibe sowohl meinen Milan als auch meine Falcons mit MagiC und großen Platten, die ich nur mit F32 nutzen kann, und habe dort keine besonderen Probleme mit Datenverlusten. Jedenfals nicht auf dem Milan und dem CT2A Falcon, die CT63 Kiste ist ein anderes Thema.Habt Ihr, @KarlMüller und @Ektus , denn auch mal zur Abwechslung mit MiNT darauf zugegriffen?
MfG Ektus.
warum ich MAGX schreibe und nicht MAGIC: Einerseits gibt es unter letzterem Namen ein anderes Produkt (nämlich eine Lib von PH)Mir ist zwar nicht klar was das mit dem Problem zu tun hat, aber wenn dann doch etwas richtiger.
denn auch mal zur Abwechslung mit MiNT darauf zugegriffen?Wenig, da ich zu 99% immer MagiC nutze. Unter MagiC regelmäßig, gab Zeiten da war es täglich.
MAGX_6.xx hat die Treiber für F32 schon an Bord, also kann man davon auch booten. Jedoch darf man wg. eines Bugs damit nur lesen, nicht schreiben! Auch nicht mit einem BootSelektor! Am besten sofort schreibschützen!Dann sind auch die anderen Randbedingungen zu nennen.
Ich wechsele fast täglich mehrfach zw. MAGX & MINT hin & her (und kann so die Vorteile beider Welten nutzen und die Nachteile vermeiden). Vielleicht hätte ich, um dem Fehler auszuweichen, die F32-Partition auch unter MAGX zum Schreiben nutzen können (und dann für MINT schreibschützen). Wg. des Zähl-Fehlers in MAGX (der dann in MiNT wie gesagt _nicht_ auftritt) habe ich mich umgekehrt entschieden. Wäre schön, wenn sich herausstellen würde, daß es sich um einen Fehler in MINT handelt, denn dann könnte man ja auf Abhilfe hoffen (während MAGX diesbezüglich leider nicht mehr gepflegt wird). Der Zähl-Fehler ist jedenfalls eindeutig ein Bug in MAGX! Immerhin weiß ich jetzt, daß er nicht nur bei mir auftritt, Danke! Sehr seltsam, daß die History behauptet, er sei behoben.denn auch mal zur Abwechslung mit MiNT darauf zugegriffen?Wenig, da ich zu 99% immer MagiC nutze. Unter MagiC regelmäßig, gab Zeiten da war es täglich.
Mag ja sein das eine Verwendung von F32 zwischen MagiC und FreeMiNT zu Problemen führt weil eines der BS einen Fehler hat.
Oder geht es nur darum zu beschreiben, wie das bei mir mit nachgeladenem MAGX funzt?Es geht darum das man bei MagiC für F32 den Schreibschutz aktivieren soll. Diese Aussage kann ich so pauschal nicht bestätigen. Wenn es Deinen Erfahrung ist dann schreib es dazu.
Der Herr Kromke hat ja noch AtariX für OSX heraus gebracht -> http://forum.atari-home.de/index.php?topic=10433.msg83957#msg83957Ein Patch wäre natürlich super. Meine stille Hoffnung war, daß vielleicht schon einer hier oder sonst wo kursiert. Btw., gibt´s irgendwelche anderen Pätsche?
Hast du ihn mal angesprochen, vielleicht kann man dieses FAT32 Problem irgendwie wegpatchen ?
Nein, AK habe ich bisher nicht kontaktiert. Wie spricht man den an? […]
PS1: Als mitten in meiner Assistentenzeit die Studenten von einem Semester auf´s andere plötzlich anfingen, mich zu duzen, habe ich, als Mathematiker, zunächst ziemlich kariert geguckt.
Nein, AK habe ich bisher nicht kontaktiert. Wie spricht man den an? Mit ´Herr Kromke´? Ist der so steif und unnahbar? Stimmt seine eMail-Adr. noch? Was macht denn der jetzt so?
Hast Du sowohl unter MAGX als auch unter MINT lesend _und_schreibend_ auf F32 zugegriffen?Ja
Gab es dadurch _unter_MINT_ weder Zähl-Fehler noch andere?Keine Fehler
Und wenn nicht, wie sehen Deine ´Randbedingungen´ aus?MagiC 6.20 (02.10.2000)
...
aber der relevante Teil, nämlich NFS, ist doch seither unverändert, oder irre ich?
...
MiNT 1.15.9 (die 1.18 läuft bei mir nicht, da unverträglich mit BlowUp & TrueDisk),Keine Ahnung, da musst Du die ChangeLogs und die Bemerkungen im Sourcecode durcharbeiten.
aber der relevante Teil, nämlich NFS, ist doch seither unverändert, oder irre ich?
Welches Boot-Prg. benutzt Du denn für MAGX?Das welches bei MagiC Milan dabei war.
Tritt bei Dir (oder Euch anderen) der ´Maus-Fussel´ auf? Das ist ein weiterer Bug in MAGX, der vom Boot-Prg. abhängtKenn ich nicht.
Leider habe ich keinerlei Hinweise, wie sich die Boot-Prge. unterscheiden.Häng beide an, dann kann man sie analysieren.
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.
Extrakt aus dem LIESMICH des HDDRIVER 8.45
____________________________________________
- Fehler in HDDRUTIL behoben, der bei FAT32-Partitionen zu einer um einen
Sektor zu kleinen FAT fhren 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 fr 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 durchgefhrt werden. Wird ein Laufwerk
nur lesend verwendet, werden auch ungltige Eintr„ge im FSINFO-
Sektor nicht gltig 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).
Aber was muß/darf ich für die Args. angeben (zB. die ´Volume ID´)?
Ganz ohne Kapazitäts-Angabe? Heißt das, man kann mkfatfs nur auf schon bestehende Parts. loslassen?
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.
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?!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.
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?
... und ich frage mich, wie kompatibel XHDI mit DOS ist ...
Mein Verdacht ist, daß die zweite FAT von NFFS/mkfatfs nur gefakt wird, um TOS zufriedenzustellen,mkfatfs legt die Anzahl der FATs an, welche Du beim Parameter -f angibst. Da wird nichts gefakt.
Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden?Kein Ahnung mehr. Kann sein das HDDRIVER dies noch nicht konnte und da habe ich mich nach entsprechenden Alternativen umgeschaut.
Tatsächlich scheint es also _unter_TOS_&_Co_ nur einen einzigen Treiber für FAT32 zu gebenDer Festplattentreiber hat nichts mit dem Dateisystem zutun. Oder warum kann ich mit FreeMiNT auf eine ext2 zugreifen und mit MagiC nicht? Der Festplattentreiber liefert die unterste Schicht beim Zugriff auf Datenträger.
Ich kann mir aber vorstellen, daß MAGX sich zu DOS kompatibel verhält,Für Dateisystem gibt es Regeln wie es auszusehen hat. Wenn überhaupt kann man Rücksicht auf kaputte Implementierung nehmen.
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.Uwe Seimet wird das Ganze zurückweisen, weil das nichts mit der SCSI-Spezifikation zu tun hat.
Irgendwie werde ich das Gefühl nicht los, daß Du da was durcheinanderbringst:Und ich habe immer wieder das Gefühl, daß Du in meinen Texten nur nach vermeintlichen Fehlern suchst, anstatt Dich nach Kräften konstruktiv um Verständnis derselben zu bemühen. Aus dem Kontext (-> #25) geht doch klar hervor, daß immer das Gesamtpaket gemeint ist (also einschl. der Tools, ibs. HDU), wenn ich ´Treiber´ oder ´HDDR.´ schreibe. Wie wär´s, wenn Du bitte mithelfen könntest, die beiden drängenden offenen Fragen schlüssig zu beantworten:... und ich frage mich, wie kompatibel XHDI mit DOS ist ...Die Antwort ist: gar nicht.
DOS und XHDI sind zwei Paar Stiefel. DOS (damit meinst Du wohl Treiber für FATxx) ...
Wenn Dir mein Versuch der Erklärung nicht gefällt, dann mach´ doch mal einen eigenen Vorschlag, wie og. 2) aufzulösen ist.Mein Verdacht ist, daß die zweite FAT von NFFS/mkfatfs nur gefakt wird, um TOS zufriedenzustellen,mkfatfs legt die Anzahl der FATs an, welche Du beim Parameter -f angibst. Da wird nichts gefakt.
Heißt das, man kann ein beliebiges HDU zur Partitionierung mit FAT16 (sic!) nehmen, aus dem AHDI, dem ICD, dem GEsoft, dem SCSITOOL oder was auch immer, und nach Anwendung von mkfatfs erhält man daraus ein FAT32 ? Denn ich habe ja oben gelernt, daß mkfatfs nur auf eine schon bestehende Partition angewendet werden kann, und ein eigenes Tool, um eine originäre Partitionierung zu erstellen, hat MiNT doch wohl nicht.Wie seid Ihr denn überhaupt auf die Idee gekommen, anschließend noch mkfatfs anzuwenden?Kein Ahnung mehr. Kann sein das HDDRIVER dies noch nicht konnte und da habe ich mich nach entsprechenden Alternativen umgeschaut.
Vielleicht solltest Du künftig dazuschreiben, welche deiner Fragen Du nicht als Frage verstanden haben willst.Irgendwie werde ich das Gefühl nicht los, daß Du da was durcheinanderbringst:... und ich frage mich, wie kompatibel XHDI mit DOS ist ...Die Antwort ist: gar nicht.
DOS und XHDI sind zwei Paar Stiefel. DOS (damit meinst Du wohl Treiber für FATxx) ...
Und ich habe immer wieder das Gefühl, daß Du in meinen Texten nur nach vermeintlichen Fehlern suchst, anstatt Dich nach Kräften konstruktiv um Verständnis derselben zu bemühen.
Aus dem Kontext (-> #25) geht doch klar hervor, daß immer das Gesamtpaket gemeint ist (also einschl. der Tools, ibs. HDU), wenn ich ´Treiber´ oder ´HDDR.´ schreibe. Wie wär´s, wenn Du bitte mithelfen könntest, die beiden drängenden offenen Fragen schlüssig zu beantworten:Ich bin nicht in der Lage, dir diese beiden Fragen zu beantworten, weil ich kein MagiC habe. Bei mir läuft nur MiNT. Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen. Dabei ist es egal, ob ich das FAT32-Dateisystem mit mkfatfs.ttp auf dem Atari oder mit mkfs auf dem PC angelegt habe.
1) Was ist die Ursache der in #17 dargestellten Katastrophen?
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?
[/color]Es wäre zB. schon hilfreich zu wissen, wie die Größe einer FAT festgelegt wird und warum und durch wen. Das sind wirklich Detail-Kenntnisse, die mir fehlen.Die nutzbare Größe von FAT-Partitionen, die mit unterschiedlichen Tools auf derselben Partition angelegt wurden, muß nicht unbedingt übereinstimmen.
Aus deinen Beschreibungen entnehme ich, daß MagiC nicht nur die betroffene Partition, sondern u.U. die gesamte Platte kaputtschreibt. Wenn das passiert, liegt der Fehler m.E. eindeutig dort.
und1) Was ist die Ursache der in #17 dargestellten Katastrophen?Ich bin nicht in der Lage, dir diese beiden Fragen zu beantworten, weil ich kein MagiC habe. Bei mir läuft nur MiNT. ...
2) Wie ist der im ScreenShot von #27 belegte Widerspruch zu erklären?
Die nutzbare Größe von FAT-Partitionen, die mit unterschiedlichen Tools auf derselben Partition angelegt wurden, muß nicht unbedingt übereinstimmen.völlig daneben sind! Deshalb noch mal gaaanz langsam zum mitmeißeln: Bei der Frage_2 ist erstens MAGX in keinster Weise beteiligt und zweitens habe ich da nicht zwei verschieden angelegte Parts. verglichen, sondern ein und dieselbe Partition R mit drei verschiedenen Werkzeugen betrachtet, nämlich
Trotzdem können beide Partitionen korrekt angelegt sein.
Insofern ist mir unverständlich, warum Du deinen Fehler anscheinend auf der MiNT-Seite suchst.wäre damit wohl auch geklärt, bis auf die Kleinigkeit, daß es sich da nicht um _MEINEN_ Fehler handelt: Genausowenig, wie ich mit fremden Federn geschmückt werden möchte, so möchte ich auch nicht mit fremdem Dreck beworfen werden.
Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe. Aber weder Deine noch meine Erfahrung ist ein Beweis, daß der Fehler bei MAGX liegt, und nicht bei MiNT oder gar HDDR.
Aus deinen Beschreibungen entnehme ich, daß MagiC nicht nur die betroffene Partition, sondern u.U. die gesamte Platte kaputtschreibt. Wenn das passiert, liegt der Fehler m.E. eindeutig dort.So habe ich ja zunächst auch gedacht (-> Anfang des Threads), aber dann kamt Ihr mir ja mit mkfatfs und dem Argument, daß damit wechselnder Zugriff unter MAGX & MiNT problemlos sei: Das begründet einen Zweifel an dieser These, wie auch die Tatsache, daß bei den oben in #17 referierten Tests nur einmal die ganze Part.-Tabelle, ein andermal aber nur die FAT32-Part. kaputt war.
Der FAT32-Treiber merkt nicht, daß seine Clusterberechnungen (aus welchen Gründen auch immer) einen physikalischen Sektor ergeben, der außerhalb der Partitionsgrenzen liegt und schreibt unabgefangen da hin. Ohne das geprüft zu haben, würde ich sogar fast annehmen, daß das *nicht* über den XHDI-Treiber (sondern über das "altmodische" Rwabs()) passiert (weil der nach meiner Erinnerung nur mit logischen Sektornummern arbeitet, das also eigentlich gar nicht kann).steuerst Du nun doch noch etwas bei, was uns vielleicht der Lösung näher bringt - aber genau da bin ich mit meinem Latein am Ende.
Riecht für mich irgendwie nach einem signed/unsigned Fehler.
Momentan stocherst du im Nebel, denn du weißt nicht, ob MagX oder MiNT die korrekten Angaben macht.indem Du nicht gemerkt hast, daß die Frage_2, die die Korrektheit der von mkfatfs gemachten Angaben in Zweifel zieht, zunächst mal gar nichts mit MAGX zu tun hat (und erst relevant wird für das og. böse 3eck, in dem MAGX involviert ist, wenn sie zuungunsten von MiNT beantwortet werden muß), aber Du steuerst ein paar neue Ideen bei, die ich mal näher betrachten möchte.
Rein Interesse halber wäre auch mal interessant, was TOS zu einer kleinen Fat32 Partition sagt (also je nach TOS-Version z.B. max 512 MB oder 1 GB groß), theoretisch müsste sogar das gehen, dann halt mit 7+~.3-Dateinamen statt der langen Dateinamen. Denn Fat32 wurde abwärtskompatibel gestaltet, ältere Systeme bekommen dann nur diese Kurznamen zu sehen. Und das dann mal mit DOS/Win, MinT und MagX vergleichen.Zunächst mal möchte ich klarstellen, daß Langnamen auf dem Atari erstens sowohl unter FAT32 als auch FAT16 eingerichtet werden können und zweitens weder unter Fat16 noch FAT32 eingerichtet sein müssen. Meine FAT32er benutzen _keine_ Langnamen. Ein Dilemma ist höchstens, daß man sie unter Windoof nicht abstellen kann. Desweiteren ist es leider so, daß TOS (sic!) FAT32-Parts. schlicht ignoriert. Dafür braucht man MAGX oder MiNT.
ZitatAuf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.
Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht.
VFAT (Virtual File Allocation Table) ist eine Erweiterung des FAT-Formats zur Verwendung langer Dateinamen, die auf FAT12, FAT16 und seit dessen Einführung im Jahr 1997 auch auf FAT32 angewendet werden kann.
Und FAT32 ist abwärtskompatibel zu FAT16, das heißt, eine FAT32-Partition, die die Größenbeschränkung von FAT16 einhält, ist von einem FAT16-System beschreib und lesbar, es sieht nur die langen Dateinamen nicht.
Alte DOS-/Windows-Versionen (bis einschließlich Windows 95A, Windows NT bis Version 4.0, MS-DOS bis 6.22, PC DOS bis 2000, DR-DOS bis 7.03) können nicht darauf zugreifen.
In Windows 95 und später findest du die Referenzimplementierung von FAT32.FAT32 ist mit dem OEM Release Windows 95 B [4.00.1111 / 4.00.1212 / 4.00.1214 - Service Release 2/2.1] in Windows 95 gekommen. Die Clusternummerierung ist dort 32 Bit breit, was es erlaubt, auch auf grossen Platten kleine Cluster zu erzeugen und damit die Platte effizienter auszunutzen. Aber lange Dateinamen kannte Windows 95 / MSDOS 7 schon von Anfang an, darum ist die Aussage:
Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht. Das wurde erst mit FAT32 eingerichtet.eben falsch- VFAT ist unabhängig von der Breite der Clusteradressen, Dateinamenlänge und Clustergröße haben nichts miteinander zu tun. Bei VFAT kann ein Dateiname sich über mehr als einen Directory-Eintrag erstrecken. Der 1. Eintrag im Directory bekommt einen auf 8 Zeichen gekürzten Namen mit der Tilde und enthält einen Verweis auf den nächsten Directory-Eintrag mit dem Beginn des langen Namens. Der wiederum verweist auf den Fortsetzungseintrag usw. bis alle Zeichen untergebracht sind.
Ich besitze weder Win9x noch NT-10 noch die nötigen Tools noch die Erfahrung, damit umzugehen...
Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.ZitatAuf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.
Ich hatte auch erst versucht HDDRIVER zum Einrichten der Platte zu nutzen und nur eine FAT32 Partition auf der Platte mit HDDRIVER angelegt, aber damit konnte der Mac nicht umgehen. Ich hatte die Platte nicht gemountet bekommen.Weiß US davon?
...Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.ZitatAuf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.
... sondern lieber was Sinnvolles tun.Prima!
... Screenshot nochmal studiert.Ja, das war für mich eine von drei Auffälligkeiten, wie in #27 beschrieben. (Die anderen beiden sind die Größenberechnung und das fehlende Label). Wenn sich da, wg. der Differenz um einen Sektor, irgendwo mal jmd. um 1 vertan hat: Könnte das dann zur Löschung von Root- oder Boot-Sektoren führen? Das wäre immerhin eine plausible Erklärung, warum der Schreibschutz derselben nicht gegriffen hat!
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht ...
Die beiden anderen "Auffälligkeiten" lassen sich durch einen Blick in die Quellen leicht klären:... Screenshot nochmal studiert.Ja, das war für mich eine von drei Auffälligkeiten, wie in #27 beschrieben. (Die anderen beiden sind die Größenberechnung und das fehlende Label).
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht ...
Das ist tatsächlich so - allerdings nicht so willkürlich wie Du das beschreibst, sondern als wesentlicher Bestandteil von FAT32. Es definiert im Bootsektor einen Verweis auf einen weiteren (FSINFO) Sektor (der irgendwo liegen kann, tatsächlich aber als nächstes nach dem Bootsektor-Backup angelegt wird), wo die Anzahl der freien Cluster und der zuletzt vergebene Cluster gespeichert wird. Das wird gemacht, um bei der Suche nach Freiplatz bzw. nach dem nächsten freien Cluster nicht jedes Mal die gesamte FAT "abklappern" zu müssen. Dort kann jeweils auch eine -1 als "weiß nicht" stehen.
Wenn sich da, wg. der Differenz um einen Sektor, irgendwo mal jmd. um 1 vertan hat: Könnte das dann zur Löschung von Root- oder Boot-Sektoren führen? Das wäre immerhin eine plausible Erklärung, warum der Schreibschutz derselben nicht gegriffen hat!
...
Könnte es sein, daß MAGX die Daten zur Beschleunigung seiner DateiInfo-Menues direkt hinter den Bootsektor schreibt? Und MiNT dergleichen ganz unterläßt? Und HDDR. den Unterschied nicht (er)kennt?
Also, zum mitrechnen (im ScreenShot von #27 für Part. R):
- mkfatfs macht an der Stelle keine "Größenberechnung". Die angezeigten Werte sind 1:1 die, die XHInqDev2() bzw. XHInqTarget2() (also HDDRIVER) zurückliefert. Die können gar nicht falsch sein ...
1) mkfatfs zeigt an:
2 FATs a 1.799 kb
1.799 kb
Number of Cluster ... 1.842.184 kb
-------------
macht zusammen: 1.845.782 kb
2) HDDRUTIL hat eingerichtet: 7.618.008
- 3.930.007
----------------------
3.688.001 Sektoren
= 1.844.000,5 kb
3) THING zeigt an: 1.840.388 kB
(hat also offensichtlich davon 2 FATs abgezogen) Wo also steckt der Fehler?Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs
- das "fehlende Volume Label" fehlt schlicht deswegen, weil Du keins (-n) angegeben hast. mkfatfs geht davon aus, daß Du auf einer leeren Partition ein FAT-Filesystem anlegen willst und macht keinen Versuch, aus einem evt. bereits vorhandenen Filesystem irgendwas auszulesen
-c Check filesysten as is gets builthatte ich so interpretiert, daß man sich damit die vorhandenen Werte anzeigen lassen kann; zumindest für manche scheint das ja zuzutreffen.
Das ...Wie schon gesagt, Test A) hat unter MAGX gecrasht, aber Test B) unter MiNT. Ansonsten war ich mit meiner Analyse ja schon vor ein paar Jahren gerade so weit gekommen wie Du jetzt, ungefähr mit den gleichen Überlegungen, und hatte daraus eben die Konsequenz gezogen, meine FAT32er unter MAGX schreibzuschützen, und deshalb auch die in #1 zitierte Warnung ausgesprochen. Aber darüber sind wir ja nun schon hinaus, im negativen Sinne mit B) und vielleicht im positiven Sinne mit mkfatfs.
...
... rechnet MiNT neu.
Und da sind wir wahrscheinlich beim Kern des Problems (das auch erklärt, warum die Platte kaputtgeschrieben wird, obwohl Du nur davon liest). Es dürfte wohl so sein, daß MagiC beim Zurückschreiben des FSINFO-Sektors einfach an die falsche Stelle schreibt...
Danke, @mfro !in deiner Rechnung.Also, zum mitrechnen (im ScreenShot von #27 für Part. R):
- mkfatfs macht an der Stelle keine "Größenberechnung". Die angezeigten Werte sind 1:1 die, die XHInqDev2() bzw. XHInqTarget2() (also HDDRIVER) zurückliefert. Die können gar nicht falsch sein ...
Code: [Auswählen]1) mkfatfs zeigt an:Wo also steckt der Fehler?
2 FATs a 1.799 kb
1.799 kb
Number of Cluster ... 1.842.184 kb
-------------
macht zusammen: 1.845.782 kb
2) HDDRUTIL hat eingerichtet: 7.618.008
- 3.930.007
----------------------
3.688.001 Sektoren
= 1.844.000,5 kb
3) THING zeigt an: 1.840.388 kB
(hat also offensichtlich davon 2 FATs abgezogen)
Wie berechnet denn THING seinen Wert? Mit den gleichen MiNT-Calls?Weiß ich nicht. Aber wenn ich THING wäre, würde ich einfach Dfree() aufrufen und sicher keine BIOS-Funktion (Du erinnerst dich?...).
Ich habe da im og. SreenShot noch eine weitere ´Auffälligkeit´ entdeckt, die mir bisher entgangen war:Da solltest Du nochmal drüber nachdenken. Ich finde es nicht besonders auffällig, daß die XHDI Versionsnummer nicht mit der angesprochenen XHDI-Gerätenummer übereinstimmt.
Das Info von mkfatfs (oben links) behauptet "Found XHDI level 1.25",
aber nach Aufruf von mkfatfs.ttp R -c heißt es: "XHDI major number 12, XHDI minor number 0".
Ich verstehe diesen (meiner Ansicht nach völlig korrekten) englischen Satz als "überprüfe Dateisystem während der Erstellung". Was kann man daran als "zeige mir vorhandene Werte" interpretieren?Ah so. Dieses fürchterliche Pidgin im Info von mkfatfs
- das "fehlende Volume Label" fehlt schlicht deswegen, weil Du keins (-n) angegeben hast. mkfatfs geht davon aus, daß Du auf einer leeren Partition ein FAT-Filesystem anlegen willst und macht keinen Versuch, aus einem evt. bereits vorhandenen Filesystem irgendwas auszulesen
Zitat-c Check filesysten as is gets builthatte ich so interpretiert, daß man sich damit die vorhandenen Werte anzeigen lassen kann; zumindest für manche scheint das ja zuzutreffen.
IS: Wie soll man darauf vertrauen, daß ein Progr´er eine P.-Sprache beherrscht, wenn er das noch nicht einmal für einfache Fälle der Grammatik der Umgangssprache schafft!Warum mußt Du's uns eigentlich immer so schwer machen, dich sympathisch zu finden?
Warum mußt Du's uns eigentlich immer so schwer machen, dich sympathisch zu finden?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´).
-c Check filesysten as is gets builtKann 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.
Stünde da das Wort ´device´, so hätte sogar ich das erkannt...Zitat..."XHDI major number 12, XHDI minor number 0"....Gerätenummer...
...BIOS... (Du erinnerst dich?...).Nicht ich habe unnötig das BIOS erwähnt, sondern Du (Du erinnerst Dich?)!
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?!...in deiner Rechnung.
Wo also steckt der Fehler?
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.
... denn mkfatfs suggeriert mit seinen Zwischen-Überschriften, daß es die vorhandenen Parameter ausgiebt, aber das ist ja falsch, wie wir mittlerweile gesehen haben
Physical informations about partition...:
-----------------------------------------------------
Logical informations about partition...:wie in den ScreenShots zu sehen.
------------------------------------------------------
Warum eigtl. meldet mkfatfs mitunter "out of Memory", obwohl noch 1,5MB frei sind?
... Warum eigtl. meldet mkfatfs mitunter "out of Memory", obwohl noch 1,5MB frei sind?
@ari.tao : Eingabeaufforderung als Admin auf machen,...Wie geht das unter Windows 8.1 ?
... und dann den Befehl "chkdsk x:" ...Wo zu finden?
Das müßte doch wohl nicht sein?!... Warum eigtl. meldet mkfatfs mitunter "out of Memory", obwohl noch 1,5MB frei sind?Weil nicht genügend freier Speicher da ist.
mkfatfs allokiert Speicher für (alle) FAT-Sektoren, den F32_INFO- und den Bootsektor und das Wurzelverzeichnis.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Tao>chkdsk e:
Der Typ des Dateisystems ist FAT32.
Volumeseriennummer : 9016-4EF8
Dateien und Ordner werden überprüft...
Die Datei- und Ordnerüberprüfung ist abgeschlossen.
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
31.248.384 KB Speicherplatz auf dem Datenträger insgesamt
64 KB in 2 versteckten Dateien
6.368 KB in 197 Ordnern
1.911.872 KB in 3.671 Dateien
29.330.048 KB sind verfügbar
32.768 Bytes in jeder Zuordnungseinheit
976.512 Zuordnungseinheiten auf dem Datenträger insgesamt
916.564 Zuordnungseinheiten auf dem Datenträger verfügbar
C:\Users\Tao> Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Tao>chkdsk g:
Der Typ des Dateisystems ist FAT32.
Volume XCHANGE erstellt 21.02.2017 23:32
Volumeseriennummer : 683F-28D2
Dateien und Ordner werden überprüft...
Windows hat auf dem Datenträger Fehler gefunden, wird diese aber nicht repariere
n, weil der Parameter /F nicht angegeben wurde.
Ungültiger langer Ordnereintrag wird von \DOWN entfernt...
Die Datei- und Ordnerüberprüfung ist abgeschlossen.
Das Dateisystem wurde überprüft, und es wurden Probleme festgestellt.
Führen Sie CHKDSK mit der Option "/F (fix)" aus, um die Probleme zu beheben.
5.868.544 KB Speicherplatz auf dem Datenträger insgesamt
4 KB in 1 versteckten Dateien
804 KB in 201 Ordnern
146.824 KB in 1.243 Dateien
5.720.908 KB sind verfügbar
4.096 Bytes in jeder Zuordnungseinheit
1.467.136 Zuordnungseinheiten auf dem Datenträger insgesamt
1.430.227 Zuordnungseinheiten auf dem Datenträger verfügbar
C:\Users\Tao> ^^-- Ein ´Start´ gibt´s leider nicht auf meinem Labtop mit Windows 8.1; die Windows-Taste oder ein li.Klick auf das Fenster-Symbol in der Taskleiste führt zu dieser ekligen Kachel-Oberfläche; immerhin hat Winny inzwischen von sich aus eingesehen, daß ich den Desktop bevorzuge.
Logische Sektoren sind bei FAT-"BIOS-Partitionen" immer 512 Bytes groß. Bei GPT und NTFS können Sektoren auch größer sein.Was ist eine "FAT-BIOS-Partition?"
Was der Ordner \down ist, kann ich dir nicht beantworten, das ist kein DOS/Windows-Ding.Die Meldung interpretiere ich so, daß ein "langer" VFAT-Name einer Datei/eines Ordners (oder möglicherweise auch das Volume Label, das ist für VFAT dasselbe) kaputt war und entfernt wurde. Das kann passieren, wenn man auf einem Volume mit langen VFAT-Namen mit einem Betriebssystem, das nicht damit umgehen kann, Dateien löscht oder umbenennt. Der VFAT-Name zeigt dann ins Leere (by Design).
Es gibt auf PCs zwei Partitionsschemas:
1. traditionell BIOS
2. auf PCs mit UEFI-ROM wird auch GPT unterstützt.
Was der Ordner \down ist, kann ich dir nicht beantworten, das ist kein DOS/Windows-Ding.zu bemerken, daß \DOWN kein Ordner, sonder eben doch ein ´DOS/Windows-Ding´ ist, wie ein schneller Blick in die Kopie des zweiten CLI-Outputs in #77 zeigt.
"Zu wissen, was man weiß, und zu wissen, was man nicht weiß, das allein ist wahres Wissen!" (Konfuzius)
Ja, BIOS ist eine Betriebssystemschicht, aber das traditionelle BIOS kann mit GPT nicht umgehen, sprich nicht davon booten. Das geht erst mit UEFI.
Hacki ohne UEFI geht meines Wissens nicht. Denn Mac x86 ist schon seit Ewigkeiten EFI, und kein traditionelles BIOS.
Könnt Ihr die Hackerei bitte mal in einen anderen Thread auslagern? Das ist hier nun wirklich total OT und hat mit unserem Thema "MAGX´ Macken" gar nichts mehr zu tun.
Danke.
Für FAT- und FAT32-Dateisysteme braucht's dosfsck aus den dosfstools.
Falls Du die noch hast, wär´s nett, wenn Du sie hier mal anhängst. Ansonsten wäre ich nämlich das nächste halbe Jahr beschäftigt - zunächst mal damit, ein Linux (bevorzugt RedHat) zu installieren und zu lernen, sodann den RPM in Gang zu setzen und dann noch die .RPMs auszupacken - um schließlich vorausssichtlich enttäuscht festzustellen, daß dosfsck auf dem Atari auch nicht mehr Info ausspukt als chkdsk auf der Dose, so. #77. Ich bin da vor mehr als sechs Jahren schon einmal steckengeblieben (-> Anhänge), aber vielleicht kann mir ja einer von Euch sein rpmrc ´rüberschieben (& was vielleicht sonst noch fehlt), dann geht´s vielleicht etwas schneller.ZitatFür FAT- und FAT32-Dateisysteme braucht's dosfsck aus den dosfstools.Ich meine, die habe ich mir auch mal installiert, weil die bei easymint nicht dabei waren.
Winrar macht das auch7Zip kanns auch, und wahrscheinlich jeder andere Packer unter Win auch.
Weiß denn koiner, was es mit der Meldung
"Start (2) does not point to .."
auf sich hat?
Eine praktische Auswirkung habe ich nicht feststellen können. Die Dirs. lassen sich problemlos im Fenster öffnen, und auch zurück zum Parent-Dir. ".." geht´s problemlos.
Irgendeine Idee?
... LFN <"..."> ... does not point to xxx
Das ist ja noch viel absonderlicher:
LongFileNames sind und waren auf diesen Partitionen _nie_ eingerichtet!
... und danach nur unter MAGXDESK befüllt worden, ganz und gar ohne LFN!
wäre das imho ein Fehler entweder in MAGX oder in MiNT! (Habe ich unregelmäßig abwechselnd benutzt).Da würde ich widersprechen. Meiner Ansicht nach wäre es ein Fehler, wenn in einem Unterverzeichnis vorhandene, versteckte Verzeichniseinträge (das sind LFNs) _nicht_ kopiert würden. Wenn ich einen Ordner von a nach b kopiere, erwarte ich, daß der gesamte Inhalt kopiert wird.
Aber wenn es denn solche Reste sind - wie kann ich sie los werden?Die Einträge, die ins Nirwana zeigen, kriegst Du mit dosfsck weg. Die gültigen werden dabei aber stehen bleiben. Wenn's FAT12 oder 16 ist, könnte CHKDSK3 von Atari evt. helfen?
Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.wäre das imho ein Fehler entweder in MAGX oder in MiNT! (Habe ich unregelmäßig abwechselnd benutzt).Da würde ich widersprechen. Meiner Ansicht nach wäre es ein Fehler, wenn in einem Unterverzeichnis vorhandene, versteckte Verzeichniseinträge (das sind LFNs) _nicht_ kopiert würden. Wenn ich einen Ordner von a nach b kopiere, erwarte ich, daß der gesamte Inhalt kopiert wird.
Nein, auf meinen FAT16ern habe ich so etwas immer gleich gelöscht, sowie ich das bemerkt habe.Aber wenn es denn solche Reste sind - wie kann ich sie los werden?Die Einträge, die ins Nirwana zeigen, kriegst Du mit dosfsck weg. Die gültigen werden dabei aber stehen bleiben. Wenn's FAT12 oder 16 ist, könnte CHKDSK3 von Atari evt. helfen?
Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.
Die heilige Kuh der Kompatiblitäthüten oder noch besser, Ziegen bei
...Erdogan...denn Erdokhan braucht ja dringend neues Personal.
...Fehler im Dateisystem ... daß der ".."-Directoryeintrag nicht auf den korrekten Startcluster des Parent-Verzeichnisses zeigt. Im Fall des Root-Directories...Das Dateisystem zeigt aber, wie schon in #102 angemerkt, keinerlei ´Symptom´. Irritierend auch, daß die Meldungen genau die erste Dir.-Schicht nach der Root betreffen (und nicht die Root selbst - die hat ja kein Parent). Deshalb vermute ich eher, daß das Dateisystem total iO. ist und der Fehler bloß in dosfsck liegt. Was genau ändert denn dosfsck, so daß die Meldungen _beim_Wiederholungslauf_nicht_mehr_ auftreten?
...mir scheint ich habe dich da auf eine falsche Fährte geschickt.Nicht so schlimm, denn wir haben ja etwas gelernt dabei (ie. hoffentlich diesmal nicht nur ich selber ;) ).
... KleinWeich...Die Antwort auf Deinen Beitrag #115 @1ST1 , ist doch schon in #47 enthalten.
Bestimmt nicht....Fehler im Dateisystem ... daß der ".."-Directoryeintrag nicht auf den korrekten Startcluster des Parent-Verzeichnisses zeigt. Im Fall des Root-Directories...Das Dateisystem zeigt aber, wie schon in #102 angemerkt, keinerlei ´Symptom´. Irritierend auch, daß die Meldungen genau die erste Dir.-Schicht nach der Root betreffen (und nicht die Root selbst - die hat ja kein Parent). Deshalb vermute ich eher, daß das Dateisystem total iO. ist und der Fehler bloß in dosfsck liegt.
If the parent of the current
directory is the root directory (see below), the DIR_FstClusLO and
DIR_FstClusHI contents must be set to 0. All date and time fields must be set to
the same value as that for the containing directory.
Was genau ändert denn dosfsck, so daß die Meldungen _beim_Wiederholungslauf_nicht_mehr_ auftreten?s.o.
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 (http://read.pudn.com/downloads77/ebook/294884/FAT32 Spec (SDA Contribution).pdf)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?
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.
. Warum wird die Plattengeometrie verändert? (255 heads)
Gibt´s auch etwas ähnliches zu Partitionierungs-Schemata & RootSektor?Du verwendest doch Atari-Partitionierung, oder? Das steht im Profibuch.
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.
Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.Mit 6.1
Wann kam denn FAT32 hinzu?
mkdosfs -a -f 2 -F 32 -s 2 /dev/loop0 140000
(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 mitCode: [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:
(https://forum.atari-home.de/index.php?action=dlattach;topic=13354.0;attach=23345)
"Bytes belegt" und "Bytes frei" sind Nonsense, "Bytes gesamt" und Anzahl Cluster stimmt aber.
Von MagiC/Jinnee:
(https://forum.atari-home.de/index.php?action=dlattach;topic=13354.0;attach=23343)
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:
(https://forum.atari-home.de/index.php?action=dlattach;topic=13354.0;attach=23344)
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).