Hardware > Emulatoren

AtariX => MagicOnLinux

<< < (80/87) > >>

AndreasKromke:
Funktionierende symbolische Links sind eine echte Herausforderung. Soweit ich das sehe, funktionierten  die vermutlich nicht einmal bei MagiCMac vollständig.

Insbesondere knifflig sind solche Links, die auf ein anderes Dateisystem zeigen. Ich kann beispielsweise A: als Disketten-Image einhängen, in "C:\MP" einen Link namens "AO" erzeugen, der auf "A:\ORDNER\" verweist, und dann einen Zugriff machen auf "C:\MP\AO\BA\BEISPIEL.TXT". In diesem Fall kann der Link AO kein gültiger Unix-Link sein, weil es dort ja kein Laufwerk A: gibt. Die Pfadauswertung im HostXFS muß dann bei "C:\MP\AO" abbrechen und dem Kernel sagen, daß er bei "A:\ORDNER\" weitersuchen soll, und zwar nach "BA\BEISPIEL.TXT". Der Kernel kann das, aber das HostXFS nicht, und das aus gutem Grund, denn der Aufwand dafür ist beträchtlich.

Was ich immerhin hingekriegt habe (hoffentlich), sind symbolische Links innerhalb des HostXFS, solange sie nicht relativ sind UND das virtuelle Laufwerk verlassen. Dann knallt es, was es natürlich nicht darf. Da sind auch sicherlich noch mehr Fehler drin; die Fehlermöglichkeiten sind unerschöpflich.

Thorsten Otto:

--- Zitat von: AndreasKromke am Fr 20.02.2026, 12:40:06 ---Funktionierende symbolische Links sind eine echte Herausforderung.

--- Ende Zitat ---

Ja, das ist knifflig. Insbesondere bei absoluten symlinks. Soll bei einem link '/etc/localtime' auf die Host-Datei zugegriffen werden, oder auf `U:\etc\localtime`? Beides kann, je nach Situation, sinnvoll sein. Wobei idealerweise irgendeine Option vorhanden sein sollte, die jeglichen Zugriff auf Pfade ausserhalb der konfigurierten Host-Pfade unterbindet.

Was bei MagiC noch dazu kommt, ist daß der Kernel beim Parsen von Pfadnamen nur '\' als Trenner akzeptiert, aber nicht '/'. Das müsste man mal (auch aus Kompatibilität zu MiNT) ändern.

AndreasKromke:
Kommando zurück: Das mit den Links auf andere HostXFS-Laufwerke klappt nur manchmal. Es geht wohl nur, wenn das Ziellaufwerk schon mal geöffnet war. Keine Ahnung, woran das liegt, alles zu kompliziert.

AndreasKromke:
Es ist vollbracht:

Um die symbolischen Links vollständig zu unterstützen, mußte ich die XFS-Schnittstelle um ein paar Parameter erweitern. Bei dieser Gelegenheit habe ich endlich alle Verweise auf das alte macOS aus dem Kernel rausgeworfen und die Schnittstelle großteils neu gemacht.

Der Kernel tut nun das, was ich 1994 auch schon hätte einbauen müssen, nämlich alle XFS-Aufrufe blind weiterzuleiten, mit den internen Deskriptoren, ohne daß sich der Kernel darum kümmert, was der Host da in seine privaten Bereiche reinschreibt. Das HostXFS hat jetzt rund 80 Bytes in diesen Blöcken zur Verfügung, die es frei verwalten kann. Insbesondere ist es jetzt nicht mehr nötig, für einige Verweise 16 Bit statt 32 zu verwenden, nur weil ich das 1994 so festgelegt hatte.

Hintergrund war damals, daß jede Datei und jeder Ordner im macOS durch zwei Zahlen eindeutig referenziert wurde, nämlich eine 16 Bit breite VolumeId (ein großes ELL, ich HASSE serifenlose Schrift!) und eine 32 Bit breite Datei-Id. Diese beiden Zahlen wurden schon im Assembler-Teil, also im Kernel, verwaltet, weil ich damals soviel wie möglich im MagiC-Kernel machen wollte und so wenig wie möglich im macOS. Ein Fehler.

Der Emulator unterstützt weiterhin den vorherigen Kernel (API 3); die Funktionen sind alle doppelt vorhanden. Die alten werde ich aber demnächst rauswerfen. Wenn ihr den Emulator neu baut, achtet bitte darauf, daß ihr auch den neuen Kernel verwendet. Im Debug-Modus gibt es eine Warnung, die auf die API-Version 3 oder 4 hinweist.

Mit den symbolischen Links könnt ihr (wenn da nicht noch Fehler drin sind) jetzt natürlich auch folgendes machen:

Hänge in A: ein Disketten-Image ein, dort drin ist Ordner "BILDER".
Macht in C:\BIN einen symbolischen Link auf A:\BILDER.
etc.

Die Links können, wenn alles klappt, auch vom Host aus erzeugt werden (ln -s). Ihr könnt auch einen Atari-Pfad angeben ("ln -s A:\\BILDER A.LNK"), dann zeigt der Link natürlich im Host ins Leere. Wenn der Link vom Atari erzeugt wird, versucht er, einen Host-Link zu erzeugen, und wenn das nicht geht, weil das Ziel-Volume nicht vom Host zugreifbar ist, gibt es einen Atari-Link, auch z.B. auf U:\PROC.

Der ganze Quatsch sollte auch vom MCMD aus gehen, weil die alten Funktionen (Fsfirst/next/attrib etc.) symbolische Links transparent behandeln sollten.

AndreasKromke:
(Fehfunktion)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete