🚀 go-pugleaf

lukas@phoenix.tp1.ruhr-uni-bochum.de (Lukas Wunner) wrote:
> 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. 

Schoen ung gut...aber was machst du z.B. mit all den tausend ASCII Dateien 
(rib, ps, NSDict-archives, etc.) die sich zwar an eine gewisse Konvention 
(Anfangskommentare) einhalten k�nnen...aber nicht m�ssen (und sehr oft auch 
nicht tun).
Bei allem was binary ist mag es sein, da� man so einen Magic eingebaut 
hat...sicher ist das jedoch auch nicht f�r alle Datens�tze.

Und dann gibt es da ja noch die riesige Menge an typed Streams unter 
NeXTSTEP.
Das ist auch der Grund warum ich z.B. gerne zwei Eintr�ge h�tte. (Dateityp & 
Encoding Type)
Denn es gibt viele Datens�tze unter OPENSTEP die vom encoding alle gleich 
sind und sich evt mit bestimmten tools verarbeiten lassen, wobei die Tools 
jedoch mit dem tats�chlichen Inhalt nicht sehr viel anfangen k�nnen (wollen)

Alles das gleiche Encoding...aber ganz anderer Inhalt. Hier gibt es eigntlich 
kein "Magic" in dem Sinne.

File ist ein netter Versuch aber nicht unbedingt die L�sung wenn man mal 
etwas kritisch ist.


> Wenn Du den Dateityp ueber Metainformationen
> (Extension, oder auch der Type/Creator beim Mac) speicherst, kommen zwangs-
> laeufig immer Inkonsistenzen zustande. 

Naja...Inkonsistenz kann man sicherlich erzeugen...aber per Default sind sie 
eigentlich nicht vorprogrammiert, wenn man den Mac Weg geht.
Extensions ala UNIX machen es dem Benutzer etwas sehr leicht sich zu 
verhauen.

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

Was ja nicht unbedingt schlecht ist...warum soll sich der Bentuzer darum  
k�mmern wie es zu den Dateitypen kommt. Solange es dokumentiert ist und 
Systemverwalter in der Lage sind einzugreifen sofern es Schwierigkeiten gibt.

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

Kann ich voll verstehen und unterschreiben. Diese BunchTyper etc.pp. 
Geschichte ist sehr unsch�n. Man sollte diese Dinge irgendwo auf 
Finder/Workspace Seite bereits �ndern k�nnen...wobei hier z.B. ja sowas wie 
die "Magic" Database ins Spiel kommen sollte und den Benutzer darauf 
hinweisen, da� er dabei ist seine Datei zu "zerkonfigurieren" sofern das 
erkennbar ist.

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

Vom Ansatz ist die Indigo Geschichte nicht schlecht und ist sicherlich das 
Maximum was man aus dem UNIX Dateisystem ziehen kann.
Wenn NeXTs Workspace diese "magic" mappings beachten w�rde k�nnte man evt. 
diverse Probleme beim umbennen usw etwas entsch�rfen.

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

Yup...siehe oben.

Eine schnelle OO-Datenbank wie schon vor X Jahren f�r Mecca angedroht w�re 
sicherlich eine sehr gute L�sung f�r viele Probleme....jedoch bin ich mir 
nicht sicher ob das in Sachen "Speed" wirklich so der Hit w�re.
Mecca gammelt sicherlich noch irgendwo bei NeXT in der Schublade "cool aber 
nix zum Vorzeigen"...vielleicht lebt ja so manches wieder auf.

Aloha
	Tomi