🚀 go-pugleaf

tomi@shinto.nbg.sub.org (Thomas Engel) writes:
>Wenn man generell mit einer Art Systemweitem "MIME-Type" Mapping arbeiten 
>w�rde und je nach Dateisystem einfach nur das richtige passieren 
>wuerde...ja...sowas sollte es haben.

Unter den meisten Unix-Derivaten existiert das file(1) Kommando, mit dem
man etwas aehnliches realisieren kann. Das Kommando liest die ersten paar
Bytes einer Datei ein und vergleicht sie mit einer Datenbank in /etc/magic.
Anhand der Magic der Datei (also z.B. 0xCAFEBABE bei Java Klassen ;-) )
kann somit ihr Dateityp bestimmt werden. _Das_ ist IMHO die wirklich
beste Loesung fuer das Problem. Wenn Du den Dateityp ueber Metainformationen
(Extension, oder auch der Type/Creator beim Mac) speicherst, kommen zwangs-
laeufig immer Inkonsistenzen zustande. Beim MacOS kommt erschwerend dazu,
dass die Oberflaeche die gesamte Komplexitaet dieses Problems vor dem Benutzer
zu verstecken sucht; die Bestimmung des Dateityps ist somit fuer den Benutzer
mehr oder weniger eine Black Box, und der Vorgang laesst sich praktisch
nicht manuell beeinflussen. Die Inkonsistenzen lassen sich daher nur durch
Zusatzprogramme wie ResEdit oder BunchType oder Snitch oder was auch immer
beheben, das Betriebssystem selbst kommt mit keinen vernuenftigen Tools
fuer diese Problematik daher. Mit ein Grund weshalb mich das MacOS
schon mehrmals zum Wahnsinn getrieben hat. :-)

Ein graphischer Dateimanager wuerde nun bei einer Directoryansicht von jeder
Datei mit file(1) den Dateityp bestimmen; in einer vom Benutzer editierbaren
(und auch leicht maschinell ueber Skripte modifizierbaren) Datenbank werden
dann die Iconinformationen zu dem Dateityp, und die Filetype Rules gespeichert,
d.h. welches Menue erscheint, wenn man mit rechter Maustaste auf das File
klickt, welches Programm wird gestartet, wenn man auf die datei doppel-
klickt, uswusf.

Eine Oberflaeche, die genau dieses Verhalten realisiert, hat Silicon
Graphics entwickelt und bundelt sie seit jeher mit IRIX. Unter IRIX 3.x
war das schon so mit der WorkSpace, desgleichen unter IRIX 4.x. Wie es
jetzt mit Indigo Magic (IRIX 5.x und 6.x) aussieht, weiss ich nicht
genau. Das Betriebssystem speichert in einem Vektorformat die Icons,
d.h. man kann sie beliebig skalieren. Ueber ein Set von Filetype Rules
wird das Verhalten beim Anklicken der Datei sehr flexibel spezifiziert.

Natuerlich hat das Verfahren auch ein paar Probleme:
- es ist proprietaer; SGI hat das auf keine andere Plattform portiert und
  rueckt freilich auch nicht den Source dazu heraus.
- nicht alle Dateiformate haben ueberhaupt eine Magic, und manche Datei-
  formate verwenden identische oder aehnliche Magics, so dass keine ein-
  deutige Identifizierung des Dateityps moeglich ist.
- Bei einer Directory-Ansicht muss das System jede Datei oeffnen und die
  ersten paar Bytes lesen. Dies ist relativ zeitaufwendig, insb. natuerlich
  wenn sehr viele Dateien im Verzeichnis sind. Unter IRIX werden daher die
  gelesenen Informationen in $HOME/.workspace/ gecacht. Problem: es muss
  trotzdem bei jeder Directoryansicht zumindest geprueft werden, ob sich das
  Datum der Datei veraendert hat (dann muessen die Informationen erneut
  eingelesen werden), ausserdem frisst der gesamte Caching Mechanismus etwas
  Plattenplatz und Performance.

Insgesamt bin ich trotzdem der Meinung: wenn man ein wirklich vernuenftiges
Filetype-System auf die Beine stellen will, ist das der richtige Weg.

>NeXTs(Apples) DOS Dateisystem sollte jedoch in Zukunft auch das Win95 Format 
>mit langen Namen unterst�tzen, da man ansonsten wieder ein paar 
>Schwierigkeiten hat den Leuten die Migration von Win95 nach "MacStep" 
>schmackhaft zu machen.

Zweifelsohne. Da Apple seit geraumer Zeit eine Offenheits-Politik faehrt,
sollte das kein allzu grosses Problem sein: wenn die entsprechenden Schnitt-
stellen im Betriebssystem veroeffentlicht werden, sollte es vergleichs-
weise einfach moeglich sein, bspw. die Filesysteme vom Linux Kernel zu
portieren; und der kann mitunter VFAT, UFS, HPFS, FAT uswusf.

	Lukas.