MAGX´ Macken

[1ST1]

Winrar macht das auch

7Zip kanns auch, und wahrscheinlich jeder andere Packer unter Win auch.

[ari.tao]

Zunächst mal vielen Dank für Eure Radschläge. Um sie zu verfolgen, habe ich einigen Aufwand betrieben, darum ging´s nicht so schnell mit der Antwort. Hier nun die Ergebnisse:

I) Auf der von @mfro verlinkten SpareMiNT-Site
   http://www.sparemint.org/sparemint/html/packages/
findet sich nicht nur dosfstools, sondern auch rpm. Letzteres ist die nötige Ergänzung zu dieser Googelei
   https://sites.google.com/site/probehouse/mint-os-for-atari/mint-and-rpm
einer zunächst aussichtsreich erscheinenden Anleitung zur Installation von RPM, deren Links aber leider in die Irre führen...
Jedenfalls habe ich so die oben erwähnte bei mir fehlende Datei rpmrc etc. ergänzen können und tatsächlich RPM.TTP auf dem Falcon grundsätzlich zum Laufen gebracht.
Dennoch habe ich die Idee, .RPMs auf meinen Ataris auszupacken, inzwischen aufgegeben, denn RPM ist nicht einfach bloß ein (Ent-) Packer, sondern ein Installer in einer UNIX-artigen Umgebung und gilt außerdem als veraltet: Solch ein Dino ist für meinen Mäuse-Jäger schwer bekömmlich.

II) Die bessere Idee ist daher, .RPMs auf einer schnellen, großen Dose auszupacken. Deshalb habe ich als nächstes mal WinRAR beäugt:
   https://de.softonic.com/s/winrar-kostenlos-downloaden-deutsch-vollversion
jedoch dann lieber das als FreeWare unter GPL angebotene 7Zip:
   http://www.7-zip.de/download.html
heruntergeladen. Damit lassen sich die als .RPMs vorliegenden SpareMiNT-Tools sicher auspacken.

III) Nun also zu dosfstools. Schon ein Blick auf die Doku zeigt, daß leider, wie in #97 vorausgesehen, die erhoffte Info über FAT-Größe, -Lage etc. damit nicht erlangt wird. Ich habe trotzdem nun dosfsck.ttp auf dem Falcon ausprobiert, weil ich gehofft hatte, daß es leistet, wozu das dem Kobold beiliegende Correct.PRG auf FAT32er Parts. leider nicht in der Lage ist. Mit "dosfsck.ttp -rt x:", x = O...K... habe ich die angehängten ScreenShots erzeugt. Die ausgegebenen Meldungen auf den 255MB-Parts. helfen leider nicht weiter, und für eine 1,8GB-Part. sind 7MB freier Speicher offenbar nicht genug!
Fazit: In der vorliegenden Version ziemlich unbrauchbar.

[ari.tao]

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?

[mfro]

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?

Im ganzen Satz steht da:

... LFN <"..."> ... does not point to xxx

Wenn man (erfordert ein wenig Phantasie) "LFN" mit "large file name" übersetzt, ist klar, was da los ist: der lange Filename "..." (der ja bei VFAT als zusätzliche(r) versteckte(r) Directory-Eintrag/Einträge realisiert ist) zeigt ins Nirwana. Das passiert, wenn man bei VFAT-Dateisystemen Dateien mit einem Nicht-VFAT-fähigen OS verschiebt oder löscht (habe ich aber, glaube ich, oben schon mal geschrieben).

Das ist kein Fehler, sondern "by (Microsoft) Design". Es besteht sogar die (zwar relativ unwahrscheinliche, aber nichtsdestotrotz dokumentierte) Möglichkeit, daß auf diese Art plötzlich lange Dateinamen auf Dateien referenzieren, mit denen sie gar nichts zu tun haben. Du löschst dann z.B. versehentlich "PASSWDS.TXT" weil dummerweise der LFN "diese Datei wollte ich schon lange mal löschen.txt" drauf zeigt. Pech. Wie gesagt, kein Fehler, sondern Absicht.

[ari.tao]

Das ist ja noch viel absonderlicher:
   LongFileNames sind und waren auf diesen Partitionen _nie_ eingerichtet!

[mfro]

Das ist ja noch viel absonderlicher:
   LongFileNames sind und waren auf diesen Partitionen _nie_ eingerichtet!

Wetten, daß?

Wie sollen die LFN's sonst da drauf gekommen sein? Einmal in einen Windows-PC reinstecken reicht u.U.

[ari.tao]

NEINNN!
Glaub mir, die sind mit HDDRUTIL eingerichtet und danach nur unter MAGXDESK  befüllt worden, ganz und gar ohne LFN!

[mfro]

... und danach nur unter MAGXDESK  befüllt worden, ganz und gar ohne LFN!

Und die Quelle war dabei was?

Nachdem LFN's für MagiC (wie für jedes andere nicht-VFAT-fähige OS) nichts anderes als Verzeichniseinträge mit gesetztem hidden-Attribut sind, kann es durchaus sein, daß es die aus einer VFAT-Quelle ganz naiv mitkopiert.

[ari.tao]

Hmm. Die Quelle war eine FAT32er, die _nur_ unter MiNT befüllt wurde - und da auch nur _ohne_ LFN. Die wiederum wurde nur von TOS- oder TOS+DOS-Parts. aus befüllt, wiederum ohne LFN. Wenn da tatsächlich solche Reste mitkopiert wurden, etwa von TOS+DOS aus (wo solche drauf sein könnten), wäre das imho ein Fehler entweder in MAGX oder in MiNT! (Habe ich unregelmäßig abwechselnd benutzt).

Aber wenn es denn solche Reste sind - wie kann ich sie los werden?
Einfach bloß Versteckte anzeigen lassen und löschen?

[mfro]

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?

[ari.tao]

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.

Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.

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?

Nein, auf meinen FAT16ern habe ich so etwas immer gleich gelöscht, sowie ich das bemerkt habe.
Werde heute Abend mal auf die Suche gehen.
Erst einmal vielen Dank für die Hilfe!
Das sich das so vererbt, da wäre ich noch lange nicht drauf gekommen.

[mfro]

Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.

Alles, was das nicht-VFAT-fähige OS zu sehen bekommt, sind versteckte, allerdings aus "nicht-VFAT-Sicht" sehr wohl gültige Verzeichniseinträge. Willst Du, wenn Du einen Ordner von a nach b kopierst, für jede einzelne Datei gefragt werden, ob Du die wirklich kopieren willst?

Das Problem ist die VFAT-Spezifikation. Typisch MS-halbgar, aber geschickt so gemacht, daß es so aussieht, als ob der Fehler bei "den anderen" läge.

[ari.tao]

Die Suche verlief negativ! Keine Überreste von LFNs auf den fraglichen Parts., auch nicht ´hidden´! Auch dieses Rätsel ist weiterhin offen...
Ich habe es gewagt, dosfsck -a -V x: mit x = M, N aufzurufen (diesmal unter MiNT). Ergebnis -> Anhang. Der dritte Lauf war eine Wiederholung des zweiten und dauerte _deutlich_ länger - wieso eigtl.? Was hat denn dosfsck verändert?
Daß die Anwendung auf die 1,8GB-Part. am angeblichen Speichermangel scheitert, hatte ich ja schon geschrieben.
Kann schon sein, daß uns KleinWeich da wieder Mist angedreht hat. Aber im Moment sind die hier aus dem Schneider. Wenn ich vom Tausch-Medium Daten ´runterkopiere, bleibt von LangNamen immer bloß eine Tilde ´~´ übrig. Auf den Parts. M & N sind überhaupt keine solchen, auch keine ehemaligen; das Material stammt ausschließlich von uralten BackUps aus Zeiten, als es noch keine LangNamen auf dem Atari gab.
Was ist denn Start (2) überhaupt?

[1ST1]

Der 8.3 Dateiname mit der Tilde wird unter Fat32 und NTFS automatisch erzeugt, denn das ist der Kurzname, den Betriebssysteme ohne LFN-Support zu sehen bekommen. Das funktioniert sogar unter Windows 10 64 Bit noch. "cd c:\progra~1" wechselt nach "c:\programme" (bzw "c:\program files") und "cd c:\progra~2" wechselt nach "c:\programme (x86)" (bzw "c:\program files (x86)"). Die heilige Kuh der Kompatiblität, selbst wenn unter 64 Bit Windows keine 16 Bit Programme mehr laufen.

Und nein, MS-DOS bzw. Windows machen auf einem FAT-Laufwerke (normalerweise) keinen Fehler. Wäre ja noch schlimmer, bei der Verbreitung heutzutage. Der Fehler muss entweder in MiNT (glaube ich weniger, da Open Source und Tausende Anwender haben da schon in den Code reingesehen) oder MagX sein. Deine Behauptung wäre ja als ob sich Erdogan als einen lupenreinen Demokraten bezeichnen würde.

[ari.tao]

^^-- Kaum bist Du da, schon riecht´s wieder nach Schwafel,  !
Wir bewegen uns gerade nicht auf Deiner geliebten WinDose, sondern auf dem Atari, und da können auch MAGX & MiNT Tilden aus LangNamen erzeugen - aber wie ich oben deutlich ausgeführt habe, gibt es auf den im ScreenShot sichtbaren Parts. keine Überreste von LFNs, also auch keine Tilden. Der neu zu Tage geförderte Fehler ist daher imho höchstwahrscheinlich keiner in MAGX oder MiNT, sondern bloß einer in dosfsck, wie die drei Buchstaben LFN in den obersten Zeilen in den MiniWin-Fenstern im ScreenShot anzeigen: Offensichtlich glaubt dosfsck zu Unrecht, daß es sich um LFN-Parts. handelt. Eine minder wahrscheinliche Möglichkeit wäre noch, daß HDDRUTIL da ´was falsch eingerichtet hat - jedoch wurde die Part. M zwischendurch mit mkfatfs behandelt (mit bloß zwei Recs./Cluster, deshalb die große Cluster-Anzahl => 19MB mehr!), das hätte also korrigiert sein müssen (außer, wenn auch mkfatfs da was falsch macht). Das wäre also ein weiterer Fall für unsere MiNTzer, aber weit wichtiger wäre es, den Speicherbedarf von dosfsck zu reduzieren. So, und nun geh mal wieder

Die heilige Kuh der Kompatiblität

hüten oder noch besser, Ziegen bei

...Erdogan...

denn Erdokhan braucht ja dringend neues Personal.

[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...

...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.

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]

...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.

Bestimmt nicht.

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.

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...