Software > Alternative Betriebssysteme
MAGX´ Macken
1ST1:
Ich beziehe mich auf diesen Satz: "Kann schon sein, daß uns KleinWeich da wieder Mist angedreht hat. "
In allen deinen Betrachtungen muss immer das, was M$ tut, bei FAT, FAT32 (und NTFS) die Referenz sein. Und im Zweifelsfall sind Tools von "Microschrott" oder wie du auch immer die Redmonder Firma von Gill Bates nennen mögst, die Referenz. Wenn ein Tool es auf dem Atari richtig macht, muss das selbe Ergennis dabei rauskommen, wie bei den BSOD-Programmierern.
mfro:
Ich habe mir die Quellen von dosfsck angeschaut und jetzt muß ich - glaube ich - Abbitte leisten.
Zumindest deine letzten Screenshots haben mit LFNs nix zu tun, mir scheint ich habe dich da auf eine falsche Fährte geschickt.
Dabei handelt es sich um echte (allerdings nach meiner Ansicht unkritische) Fehler im Dateisystem. Die Fehlermeldung "Start (<xx>) does not point to .. (<xx>>)" heißt schlicht, daß der ".."-Directoryeintrag nicht auf den korrekten Startcluster des Parent-Verzeichnisses zeigt. Im Fall des Root-Directories (und darum handelt es sich hier offensichtlich) dürfte das allerdings unkritisch sein. Laß' es dosfsck reparieren und gut ist.
Was den Speicherhunger von dosfsck angeht: das ist halt so. FAT32 ist ein Speicherfresser und dosfsck ist ursprünglich kein MiNT- sondern ein angepaßtes Linux-Programm. Dort ist Speichermangel üblicherweise kein Problem.
Und was den ursprünglichen Anlaß angeht, sich überhaupt mit dosfsck zu beschäftigen: hast Du mal den "-v"-Schalter probiert?
ari.tao:
^^-- Nein, hatte ich noch nicht. Ich habe das jetzt schleunigst nachgeholt, siehe Anhang und Diskussion weiter unten.
Was den Speicherhunger von dosfsmk und, wie früher schon mal angemerkt, auch von mkfatfs, angeht: Das ist schon ärgerlich, daß es da nun endlich ein Rep.Tool für F32 als Ersatz auch für das veraltete Correkt.PRG gibt - und dann kann man´s auf dem Falcon doch nicht benutzen. Hilft es, Outside oä. einzusetzen? Ich befürchte, dann wird das alles unerträglich lahm...
--- Zitat von: mfro am So 12.03.2017, 11:22:31 ---...Fehler im Dateisystem ... daß der ".."-Directoryeintrag nicht auf den korrekten Startcluster des Parent-Verzeichnisses zeigt. Im Fall des Root-Directories...
--- Ende Zitat ---
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?
--- Zitat von: mfro am So 12.03.2017, 11:22:31 --- ...mir scheint ich habe dich da auf eine falsche Fährte geschickt.
--- Ende Zitat ---
Nicht so schlimm, denn wir haben ja etwas gelernt dabei (ie. hoffentlich diesmal nicht nur ich selber ;) ).
-------
--- Zitat --- ... KleinWeich...
--- Ende Zitat ---
Die Antwort auf Deinen Beitrag #115 @1ST1 , ist doch schon in #47 enthalten.
IS: Durch Wiederholung wird nichts besser.
Durch Wiederholung wird nichts besser.
-------
Nun noch ein paar Worte zum ScreenShot im Anhang:
Das hatte ich nun nicht vermutet, daß sich einige, wenn auch nicht alle (aber immerhin mehr als mit chkdsk auf der Dose) - der gesuchten Infos unter der Verbose Option ´-v´ verstecken. Damit ist mein in #60 geäußerter Wunsch nun zum Teil erledigt, nämlich so weit, wie sich die Wirkung von mkfatfs nachprüfen läßt, aber leider nicht in Bezug auf den FSINFO-Sektor.
Es gibt schon auf den ersten Blick seltsames zu entdecken:
. Warum wird die Plattengeometrie verändert? (255 heads)
. Was sind denn das für absonderlich viele (ibs. auf Part. I: ) ´hidden sectors´?
. Wieso verschwinden die alle durch mkfatfs ? (auf M: )
Die Part. I: ist eine gewöhnliche 255MB Fat16er (interessant der Vgl. mit M: & N: ); ich habe auch mal das CheckFAT.PRG von TB darauf angewendet...
mfro:
--- Zitat von: ari.tao am Mo 13.03.2017, 18:47:44 ---
--- Zitat von: mfro am So 12.03.2017, 11:22:31 ---...Fehler im Dateisystem ... daß der ".."-Directoryeintrag nicht auf den korrekten Startcluster des Parent-Verzeichnisses zeigt. Im Fall des Root-Directories...
--- Ende Zitat ---
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.
--- Ende Zitat ---
Bestimmt nicht.
--- Zitat von: (Microsoft Spezifikation) ---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.
--- Ende Zitat ---
--- Zitat von: ari.tao am Mo 13.03.2017, 18:47:44 ---Was genau ändert denn dosfsck, so daß die Meldungen _beim_Wiederholungslauf_nicht_mehr_ auftreten?
--- Ende Zitat ---
s.o.
Der Fehler bleibt ohne große Konsequenz: ".." muß, wenn es auf das Root-Directory zeigt, auf 0 gesetzt sein. Bei dir ist es auf 2 gesetzt (das *ist* - jedenfalls normalerweise - der Startcluster des Root-Directories). Nichtsdestotrotz ist es (s.o.) verkehrt.
ari.tao:
Ja danke, hatte ich mir soeben genauso überlegt, nachdem ich den ersten Teil Deiner Antwort gelesen hatte.. Aber wo liegt die Ursache? Im GEMDOS des MAGX?
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...
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln