Atarium - Neues von den Links

Unmittelbar nach der CeBIT hat Application Systems, wie im Frühjahrsrundschreiben angekündigt, MagiC 3 auf den Markt gebracht. Dabei wurde die Falcon-Unterstützung erst einmal ausgeklammert, um das Release für STs und Falcons nicht noch weiter zu verzögern. Wie man allerdings hört, wird mittlerweile mit Hochdruck an den speziell für den Falcon benötigten Routinen gearbeitet (DSP, Sound usw.).

Grund genug, einige Neuerungen, die für MiNT-Benutzer nicht ganz so neu sein werden, unter die Lupe zu nehmen. Ähnlich wie MiNT, erlaubt auch MagiC 3 das Einbinden neuer Dateisystemtypen. Die Einbindung passiert auf ähnliche Weise wie bei MiNT, ganz identisch sind die Verfahren allerdings nicht (MiNT-Dateisystemtreiber haben beispielsweise Zugriff auf allerlei MiNT-interne Funktionen, die es in dieser Form in MagiC nicht gibt, und machen auch davon Gebrauch). ZurZeit wird diese Erweiterbarkeit nur von internen Dateisystemen wie den Verzeichnissen auf Laufwerk U: (u:V proc, u:\dev usw.) und dem Mac-Dateisystem in MagiCMac verwendet. Für Applikationen sind die Schnittstellen allerdings mit denen von MiNT identisch. Das heißt: wer die entsprechenden MiNT-Funktionen benutzt und sich nicht auf die Existenz des MiNT-Cookies verläßt, braucht keine weiteren Anpassungen zu machen, um beispielsweise mit langen Dateinamen zurechtzukommen.

Links

Wer bislang nicht mit MiNT und dem Minix-Dateisystem gearbeitet hat, wird möglicherweise noch nie mit ‘harten Links’ und ‘symbolischen Links’ zu tun gehabt haben. MagiC 3 unterstützt nun symbolische Links auch auf TOS-Dateisystemen. Daher will ich versuchen, diese beiden oft nicht richtig verstandenen Begriffe zu erklären.

UNIX-Dateisysteme unterscheiden traditionell zwischen der eigentlichen Datei und dem Eintrag im Verzeichnis. Der Verzeichniseintrag - der ‘Link’ - enthält in der Regel nur den Namen und einen Verweis auf den sogenannten ‘Inode’. Dieser wiederum enthält die Informationen über Zugriffsrechte (Wer darf diese Datei lesen?), Timestamps (Wann wurde diese Datei zum letzten Mal verändert?), Größe und eben einen Verweis auf den Dateiinhalt. Diese strikte Trennung hat allerlei Vorteile: zum Beispiel kann es zu einer Datei mehr als einen Link geben. Das ermöglicht es beispielsweise, ein und dieselbe Datei unter zwei verschiedenen Namen oder an zwei verschiedenen Stellen innerhalb eines Dateisystems zu führen. Dabei sollte man sich vor Augen führen, daß beide Links völlig gleichwertig sind, es gibt also nicht einen ‘richtigen’ Namen und einen anderen.

Die Funktion zum Löschen einer Datei heißt in ANSI-C nicht umsonst ‘unlink' und entfernt einen Link auf eine Datei. Der eigentliche Dateiinhalt verschwindet erst dann, wenn es keinen Link mehr gibt und keiner die Datei mehr geöffnet hat. Eine nützliche Folge dieses Konzepts ist beispielsweise, daß man eine temporäre Datei öffnen und dann den Link sofort löschen kann. Man kann dann die Datei solange benutzen, wie man sie benötigt. Sobald man sie schließt, wird der Speicherplatz automatisch wieder freigegeben. Damit kann man sich das Abräumen temporärer Dateien am Programmende sparen.

Auch auf Verzeichnisse kann es mehrere Links geben. Bestes Beispiel dafür sind die Einträge ‘.’ (zeigt auf das aktuelle Verzeichnis) und *..’ (zeigtauf das Parent-Directory). Die entsprechenden Einträge im TOS-Dateisystem sehen zwar ähnlich aus, funktionieren aber (leider) nicht ganz genauso.

Diese Art von Links sind die ‘harten’ Links. Um sie implementieren zu können, braucht man den oben angesprochenen Dateisystemaufbau. Wer sie auf dem ATARI benutzen will, kommt zur Zeit um MiNT und das Minix-Dateisystem nicht herum.

Geringere Anforderungen an das Dateisystem (und dafür größere an den Betriebssystemkern)stellen ‘symbolische’ Links (oder auch ‘Soft-Links’). Anders als bei den ‘echten’ Links wird hier nicht der Verweis auf den Inode, sondern auf einen anderen Verzeichniseintrag gespeichert. Wenn das Dateisystem beim ‘Auflösen’ eines Dateisystems auf einen solchen symbolischen Link stößt, wird der Inhalt des Links gelesen und anstelle des ursprünglichen Pfades benutzt.

Ein Beispiel: unter MiNT und MagiC 3 lassen sich symbolische Links im Wurzelverzeichnis von Laufwerk U: ablegen (da es sich bei U: nur um ein ‘virtuelles’ Dateisystem handelt, müssen sie nach jedem Systemstart neu angelegt werden). Mit dem Unix-Kommando ‘In’ kann man nun durch ‘ln-s c:\auto u:\testlink’ in U: einen symbolischen Link auf das Verzeichnis ‘c:\auto’ anlegen. Anschließend enthält ‘u:\testlink’ genau die Dateien, die sich auch in ‘c:\auto’ befinden. Wenn man ‘u:\testlink\datei’ öffnet, liestdas Betriebssystem zunächst den symbolischen Link und erkennt dann, daß er in ‘c:\auto’ fortfahren muß.

Was ergeben sich nun für Unterschiede? Eine wesentliche Abweichung zu harten Links haben wir hiermit schon kennengelernt: ein symbolischer Link kann über die Grenzen eines Dateisystems (also in der Regel einer Partition) hinausreichen. Des weiteren kann ein symbolischer Link durchaus auf eine Datei zeigen, die nicht mehr existiert (oder gar niemals existiert hat). In einem solchen Fall erhält man beim Versuch, darauf zuzugreifen, eine entsprechende Fehlermeldung (wie ‘Datei nicht gefunden’).

Insbesondere kann ein symbolischer Link auch wiederum auf einen anderen symbolischen Link zeigen. Das Betriebssystem setzt allerdings der Schachtelungstiefe eine Grenze, nicht zuletzt, um zirkulären Verweisen zu begegnen. Wenn Sie das nachprüfen wollen, können Sie in der Mupfel (oder einer anderen Unix-angelehnten Shell) mal die folgenden Befehle eingeben:

	cd u:\
	ln -s test1 test2
	ln -s test2 test1
	cat test1

Sie sollten nun die Fehlermeldung „zu viele symbolische Verweise“ (GEMDOS-Fehler -80) sehen. ‘In’ und ‘cat’ sind Bestandteil der MiNT-Tools bzw. der Mupfel-Tools (minttl02.tos, mupftl07.-tos), erhältlich in den Maus-Programmteilen (z.B.: Maus Münster 2) oder auf FTP-Servern (z.B.: ftp://ftp.uni-muenster.de/pub/Gemini).

Achtung: der angesprochene Fehler kann natürlich auch beim Setzen eines Verzeichnisses mit ‘DsetpathO’ auftreten. Leider gibt es allerlei Programme (darunter Gemini l.A), die den Return-Wert ignorieren, weil sie davon ausgehen, daß man auf jedes Verzeichnis, das ‘sichtbar’ ist, auch wirklich zugreifen kann. Das rächt sich nicht nur in diesem Zusammenhang, sondern eventuell auch unter MiNT, wenn der Zugriff auf das Verzeichnis für den aktuellen Benutzer nicht erlaubt ist.

MagiC 3 kann übrigens auch auf TOS-Dateisystemen symbolische Links anlegen. Ob man davon Gebrauch macht, muß man mit sich selbst ausmachen, denn diese Erweiterung ist nicht zu DOS kompatibel und könnte unter Umständen zu Problemen führen, wenn man einmal mit einem DOS-Rechner auf das Dateisystem zugreifen muß (für das unkritische Verhalten mit ‘normalen’ TOSsen hat MagiC-Entwickler Andreas Kromke gesorgt).

Die neue Vielfalt an Dateisystemen bringt es mit sich, daß nicht überall alles geht. Das liegt natürlich daran, daß Dateisysteme selten von Standardkomitees, sondern in der Regel von Herstellern definiert werden, die jeweils ihre ganz eigenen Vorstellungen davon haben, was wichtig ist. So kennt das TOS-Dateisystem das Archiv-Bit, während Unix-Dateisysteme normalerweise drei verschiedene Datumsangaben liefern. Zum Glück sind seit der MiNT-Version 1.12 zwei neue Opcodes für ‘DpathconfO’ normiert, über die man abfragen kann, welche Dateiattribute dem Dateisystem überhaupt bekannt sind. Damit können künftige Versionen von Gemini beim ‘Info anzeigen’ die nicht vorhandenen Dateiattribute ‘disabled’ darstellen (siehe Abbildung 1). Auch das" Programm ‘fsinfo’ aus den MiNT-Tools (siehe Hinweis weiter oben) kann diese Information anzeigen. Die genaue Definition der beiden Opcodes entnimmt man am besten den MiNT-Sour-cen (Datei file.h).

Neues von MiNT

Passend zum ersten Release von MagiC 3 gibt es auch ein neues Patchlevel der MiNT-Library, bei dem an einigen Stellen die MiNT-spezifischen Versionsabfragen beseitigt worden sind. Damit gelinkte Programme können beispielsweise auch unter MagiCMac die langen Dateinamen nutzen.

Und schließlich muß ich noch einige Informationen zum Thema des letzten Hefts (Iconification) nachtragen. Vergessen habe ich den wind_set-Opcode WFJJNICONIFYXYWH (28) sowie die wind_get-Opcodes WFJCONIFY (26) und WF_UNICONIFY (27). Mit WF_-UNICONIFYXYWH kann man die Koordinaten setzen, die beim De-iconifizieren an das Programm geschickt werden. Dies ist dann wichtig, wenn man das Fenster bereits im iconifizierten Zustand geöffnet hat. Der wind_get-Opcode WFJCONIFY liefert in intout[l] ein Flag (iconifiziert oder nicht) und in intout[2/3] die Standardmaße (Breite und Höhe) eines iconifizierten Fensters. WFJJNICONIFY liefert in in-tout[1..4] die Ursprungsmaße eines iconifizierten Fensters.

Bis zum nächsten Monat!

Julian F. Reschke