Schon sehr lange beschäftigt mich die Idee des Taggens von allem, d.h. auch von Dateien in einem Dateisystem. Bereits vor einem Jahr hatte ich eigentlich schon die Ideen dafür. Doch eines Abends habe ich sie zusammen mit rretzbach im IRC diskutiert. Es war sehr interessant und wir haben viele Probleme und teilweise auch ganz gute Lösungen dafür gefunden.
Hinweis: Dieser Artikel ist im Prinzip nicht auf Linux begrenzt, aber sämtliche Beispiele beziehen sich auf Linux oder ein Unix-artiges System.
Verzeichnisse im Dateisystem werden durch Tags ersetzt. Denn Verzeichnisebenen konstruieren um Dateien zu sortieren ist immer sehr schwierig. Und wie es uns die Bookmarks beweisen, geht das mit Tags wesentlich einfacher. Warum also nicht einfach Verzeichnisse durch Tags ersetzen? Dabei bräuchte man natürlich ein neues Dateisystem, dass statt Verzeichnissen Tags unterstützt. Dadurch sollten im Idealfall alle bisherigen Programme weiter funktionieren, ohne dass man auf die neuen Tagging-Funktionen verzichten müsste. Ein paar Beispiele:
ls /foto/2006/urlaub/
listet alle Fotos auf, die man 2006 im Urlaub gemacht hat. Das exakt selbe Ergebnis liefert
ls /urlaub/2006/foto/
. D.h. es wird intern nach Dateien, die mit foto, urlaub und 2006 getagt sind, gesucht. Sucht man Konfigurationsdateien für den Webserver Apache, macht man einfach
ls /apache/config/
. Mit
ls /
bekommt man alle Tags und alle Verzeichnisse aufgelistet. Auch in ein Verzeichnis wechseln sollte gehen, man kommt dann einfach in ein virtuelles Verzeichnis.
Vorhandene Meta-Daten wie bei Photos das Kamera-Modell oder bei Musik die Band oder das Album sollten natürlich ebenfalls gleich in Tags umgewandelt werden.
Die Tags sollten dabei zum eine in einer Zentralen Datenbank im Dateisystem gespeichert werden und zum anderen direkt bei der Datei. Hierfür könnte man z.B. IIM verwenden. Dadurch könnten die Tags auch z.B. bei Bildern, die man von Diensten wie Flickr herunterlädt, dabei sein oder Dateien, die man per Mail erhält oder bei einer Software dabei sind, sind bereits fertig getagt. Dadurch wäre natürlich auch bei einem Crash des Dateisystem nicht alles verloren.
Tags verstehe ich hierbei als freie, beliebige Schlüsselwörter, also kein festes, bereits festgelegtes Kategoriensystem. Welche Probleme das ergibt, darauf komme ich später noch einmal zurück.
Auch sogenannte Action-Tags wären natürlich möglich, d.h. dass man Tags wie action:to_read oder action:to_test vergibt und einsetzt, um seine Arbeit effizienter zu gestalten.
Dann kam natürlich gleich die Frage: Warum gibt es das denn noch nicht? Ist das wirklich so schwierig? Weil bis zu diesem Zeitpunkt hatten wir noch kaum Probleme gefunden, höchstens, dass es vielleicht ein wenig viele Dateien sind, die man im obersten Verzeichnis aufgelistet bekommt, aber naja, das bekommt man mit Caching schon in den Griff. Doch nach und nach vielen uns dann immer mehr Probleme ein.
Und einen Tag später habe ich auch noch einige Implementierungen gefunden! Weiter unten mehr dazu, jetzt erst einmal unsere Gedanken dazu:
Auf einem System wird man verständlicherweise mehrere README-Dateien haben, eben von unterschiedlichen Programmen. Spricht man jetzt solch eine Datei mit dem Tags des Programms davor an, also z.B. bei Apache
cat /apache/README
, ist ja alles kein Problem. Doch was für eine Datei bekomme ich, wenn ich
cat /README
mache? Oder wie reagiert ein Programm, wenn plötzlich in einem Verzeichnis mehrere Dateien mit dem gleichen Namen liegen?
Für dieses Problem kamen uns gleich mehrere Ideen, die mehr oder weniger sinnvoll sind. Also z.B. doppelte Dateien werden in Verzeichnis-listings ausgeblendet oder sie werden zu einem Tag/Verzeichnis, nur was ist dann in dem Tag/Verzeichnis? Okay, also keine mögliche Lösung. Dann könnte man natürlich das Prinzip von P2P-Applikationen aufgreifen und statt Dateinamen zumindest mal intern Hash-Summen verwenden. Dies würde geniale caching-Systeme ermöglichen. Z.B. sagt einem der Web-Server die Hash-Summe der Datei, die er jetzt losschicken will und dann prüft der Browser einfach kurz, ob sie schon lokal existiert und wenn ja, wird die lokale Version verwendet. Doch in dieser Hinsicht waren wir uns einig, dass dies ebenfalls keine Lösung darstellt, da die Menge an Hash-Summen kleiner ist als die Menge der verschiedenen Dateien.
Man könnte natürlich jede Datei gleich einmal mit der Seriennummer des Gerätes taggen, auf dem sie erstellt wird und noch das Datum dazu speichern. Dann könnte man sie schon einmal eindeutig identifizieren. Doch leider kann man darüber auch den Urheber identifizieren, was er dann wohl doch nicht will. Also auch keine Möglichkeit. Und was ist, wenn man 10 Dateien mit dem gleichen Namen per Mail bekommt und sie nicht getagt sind? Okay, dann könnte man sie nach dem Sender taggen. Einziges Problem: das müsste das Mailprogramm können, dann müsste man das ganze Betriebssystem und alle Applikationen verändern.
Und jetzt die Lösung des Problems, die wir gefunden haben: Bekommt das Dateisystem eine Datei zum ersten Mal zu sehen, bekommt sie eine einmalige ID, also z.B. einfach eine fortlaufende Zahl. Kommt bei einer Suchanfrage mehr als eine Datei mit dem gleichen Namen vor, wird einfach die ID hinten dran gehängt. Dabei ist die neueste Datei eines Namens ohne ID und wird als solche dann auch direkt aufgerufen wenn man sie anspricht, also z.B. bei
cat /README
bekommt man die neueste README-Datei. Dies ist sinnvoll, da man meist die neueste möchte, da man die Software z.B. gerade neu heruntergeladen hat.
In einem typischen System hat man leider nicht nur ein Dateisystem, sondern mehrere. Als Lösung sollte jedes Dateisystem, das in einem System eingehängt wird, eine ID bzw. einen Namen bekommen, also z.B. den Gerätenamen. Jede Datei, die dieses spezial-Tag hat, ist auf diesem Gerät. Also nehmen wir mal an, das Tag heißt device:sda1. Wollen wir jetzt alle Bilder mit den Tags Urlaub und 2006 dorthin kopieren, machen wir einfach
cp /urlaub/foto/2006/* /device:sda1
. Die anderen Tags der Dateien werden natürlich ebenfalls übernommen. Beim Speichern sollte dies genauso funktionieren. Gibt man kein Gerät an, sollte es ein default-device geben.
Doch kann man überhaupt so einfach die Dateisysteme zusammenfügen? Ist es überhaupt möglich, die beiden Datenbanken so einfach zu kombinieren und dann bei Suchanfragen beide zu verwenden? Das weiß ich leider nicht. Ein weiteres Problem wäre: Wie weit soll die Software erkennen, dass zwei Dateien auf unterschiedlichen Dateisystemen den gleichen Inhalt haben? Soll sie automatisch einen bit-für-bit-Vergleich machen, wenn Dateiname, Zeitstempel, Tags und Größe übereinstimmen? Oder wertet sie das automatisch als Gleicheit?
Bisher gibt es rekursive Funktionen, die also z.B. alle Dateien in einem Verzeichnis inklusive der Unterverzeichnisse löscht. So etwas würde dann in dem Tag-Dateisystem unweigerlich zu Fehlern führen. Für einen Lösungsvorschlag fehlt mir aber die nötige Kenntnis der genauen Funktionsweise dieser rekursiven Anweisungen.
Es wäre schön, wenn folgendes Funktionieren würde:
ls /image/jpg/width>=1280/
. Die Software müsste dafür Meta-Daten wie die eben benutzte Breite speichern. Dann sollte sie >= etc. in entsprechende Datenbankanfragen umwandeln. Im Prinzip sollte dies möglich sein.
Tags kommen aus Bereichen, in denen es nicht darauf ankommt, ob man einen bestimmten Eintrag findet der eben z.B. mit photo statt foto getagt wurde. Doch in einem Dateisystem sieht das leider anders aus. Hierfür müsste man also eine Alias-Funktion haben. Außerdem verwenden verschiedene Menschen Tags oft vollkommen unterschiedlich, man hat also auch ein Problem, wenn man von anderen Menschen getagte Dateien verwendet.
Auch die Sprache stellt ein Problem dar: Was ist, wenn man englische Tags bekommt, selber aber immer deutsche Tags verwendet? Also z.B. image statt bild. Tags können auch mehrdeutig sein. Apple bezeichnet z.B. sowohl einen Apfel als auch eine Firma. Somit müsste es deutsche Tags mit de: als Prefix geben, englische mit en: (und natürlich alle weiteren Sprachen) und internationale, z.B. mit int: als Prefix. Und jetzt muss man alle Tags mit Prefix benutzen und eine Übersetzungstabelle machen? Vermutlich ja. Man kann ja eine default-Sprache haben, so dass man nicht bei jedem Tag immer den Sprachcode eintippen muss.
Wie kann man eine Datei mit einem Tag ausstatten, das man noch nie benutzt hat? Okay, man kann ein neues Verzeichnis anlegen und die Datei da hinein speichern. Jetzt muss aber das Dateisystem irgendwie mit diesem leeren Tag umgehen können und es darf nicht dazu kommen, dass Müll entsteht. Von daher würde ich vorschlagen, dass ein mkdir, also das anlegen eines neuen Verzeichnisses, dazu führt, dass dieses Tag für 5 Minuten erzeugt wird und in dieser Zeit überall angezeigt wird (also in jedem anderen Tag/Verzeichnis). Sobald eine Datei dem Tag zugewiesen wird, wird es zu einem normalen Tag. Wird keine Datei zugewiesen, verschwindet das Tag nach 5 Minuten wieder.
Mit Tags bekommen wir ein großes Sicherheitsproblem. Was z.B., wenn Dateien absichtlich falsch getagt werden? Wir werden auf jeden Fall Berechtigungen für Tags und für einzelne Dateien brauchen. D.h. wer z.B. eine Datei sehen darf! Denn bisher kann man z.B. nicht einmal sehen, welche Dateien ein anderer Benutzer hat. Dateien, die ein User nicht lesen darf sollten deshalb gar nicht erst in Listings erscheinen. Und selbstverständlich sollten Tags, die ausschließlich solche Dateien enthalten gar nicht erst angezeigt werden. Dies hat natürlich als Folge, dass die Datenbankabfragen wesentlich komplexer werden. Die Gafahr von Sicherheitslücken im Tagging-System sind damit natürlich auch nicht kleiner.
Ein normaler User sollte natürlich auch nicht eine Datei xyz als Config für Apache taggen dürfen, die dieser dann verwendet. Wie man dies lösen kann, ist mir allerdings noch ein Rätsel, denn der User könnte durchaus eine Apache-Config für seinen privaten Webserver haben. Vielleicht sollte man die Dateisysteme für User-Daten und für System-Daten wirklich komplett trennen. Oder man hat ein spezielles system-Tag, das geschützt ist (also nur von root verwendet werden darf und mit dem nur Dateien getagt sein dürfen, die root gehören).
Wie man vielleicht schon gemerkt hat, ist mein Traum, dass das ganze als Dateisystem implementiert wird, das man einfach in den Linux Kernel einfügen kann und keine weiteren Veränderungern benötigt. Da ich von derartiger low-level-Programmierung noch kaum Ahnung habe, kann ich das ganze zumindest im Moment nicht selber bauen. Wenn aber jemand anderes Interesse hätte, die Ideen umzusetzen, wäre ich sehr dankbar und erfreut und diese Ideen, die ich hier geäußert habe, dürfen selbstverständlich gerne verwendet werden.
Hier möchte ich kurz alle mir bekannten Implementierungen vorstellen, weitere dürfen gerne in den Kommentaren ergänzt werden.