Wie sind wir auf das (hierarchische) Dateisystem als grundlegende Datenstruktur gekommen?

Ich bin Autodidakt und habe keinen CS-Abschluss. Je mehr ich über die Datenstruktur gelernt habe, desto mehr frage ich mich, wie wir heute noch das Dateisystem mit Verzeichnissen und Dateien als grundlegende Datenspeicherungsstruktur auf dem Betriebssystem haben.

Ich verstehe die Einfachheit, aber es scheint heutzutage, dass es von Haus aus mehr Optionen geben könnte. Soweit mir bekannt ist, war das einzige Projekt, mit dem die Grundfunktionalität des Dateisystems verbessert werden konnte, ReiserFS, bei dem festgestellt werden konnte, welche Zeile einer Datei von wem und wann geändert wurde.

Wenn ich zum Beispiel systemeigene Tags für Dateien einrichten könnte, in denen ich Bilder, Diagramme, Textverarbeitungsdokumente und ein gesamtes Code-Repository als Teil eines einzelnen Projekts markieren könnte, wäre das für mich sehr hilfreich. Da ich im Dateisystem-Paradigma festgefahren bin, weiß ich, dass ich all diese Dateien in einem einzigen Ordner / Verzeichnis ablegen kann. Was ist jedoch, wenn sie bereits in unterschiedlichen Verzeichnissen vorhanden sind und dort bleiben müssen? Ich weiß, dass es Programme gibt, die das können, aber warum befinden sie sich nicht im Dateisystem?

Etwas, das schön wäre, ist eine Art relationales Feature im Dateisystem, wie Sie es mit RDBMSes bekommen. Ich verstehe, dass das Teil von Vista / 7 sein sollte, aber das fiel auch von der Featureliste.

Sicher, jedes Programm kann eine Binärdatei speichern und jede gewünschte Datenstruktur haben. Warum kann das Betriebssystem keine komplexeren Möglichkeiten zum Speichern von Daten anbieten, die über die einfache Hierarchie des Dateisystems hinausgehen?

Beginnen Sie damit: http://en.wikipedia.org/wiki/Unix_File_System

Lesen Sie dies: http://www.unix.org/what_is_unix/history_timeline.html

Lesen Sie dann Folgendes: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Es gibt eine einfache Antwort auf die Frage, warum das Betriebssystem keine komplexeren Möglichkeiten zum Speichern von Daten bietet, die über die einfache Hierarchie des Dateisystems hinausgehen.

Weil es für das Betriebssystem zu viel ist.

Dafür gibt es Bibliotheken und Anwendungspakete.

Oracle verkauft Ihnen beispielsweise eine Reihe von Funktionen, die dem Dateisystem ähneln und die Sie mit dem Oracle-Toolset verwalten.

Python verwendet die DBM-Bibliothek, um sehr komplexe Speicherstrukturen auf der Festplatte zu erstellen.

CouchDB und Mongo (und andere) sind sehr ausgefeilte Speicherstrukturen, die einige datenbankähnliche Funktionen bieten.

Der Punkt ist, dass das Betriebssystem das Minimum tun sollte und alles ein Add-On ist.

Die kurze Antwort lautet: Jeder versteht das Dateisystem. Es erinnert sie an ein Archiv. Denken Sie an Webseiten und sogar an Fat Apps. Warum sind sie Ihrer Meinung Tabsnach so beliebt? Die Menschen können sich mit ihnen identifizieren und sie schnell verstehen.

Imaging versucht, Oma das Durchsuchen einer Datenbank nach Dateien anhand von Eigenschafts-Tags beizubringen. Mit dem Dateisystem weiß Oma, dass sich die Datei einfach dort befindet, wo sie sie abgelegt hat .

Selbst mit WinFS glaube ich nicht, dass MS das Aussehen und Verhalten des Dateisystems verlieren würde.

In jeder Antwort steckt ein bisschen Wahrheit, aber ich glaube nicht, dass es die ganze Wahrheit ist.

Was Sie auflisten, sind meist Funktionen, die Benutzer und Entwickler jeden Tag sehr vermissen.

Die Leute verstehen das baumbasierte Dateisystem genauso wenig wie ein DAG-basiertes.

Und es gibt absolut keine Entschuldigung für die pathetischen Anhänge von Dateinamen, die als Erweiterungen bezeichnet werden. Sie sind nicht nur völlig ungeeignet für ihren Zweck (Identifizierung des Dateityps), sondern auch eine endlose Quelle der Belästigung für Benutzer.

Der Grund, warum wir sie immer noch verwenden, ist eine Mischung aus einer Einstellung, die "das wird", und der tatsächlichen Notwendigkeit, die Kompatibilität mit älterem Code aufrechtzuerhalten. Ein neuer Ansatz zum Speichern von Dateien würde eine radikale Änderung der grundlegenden Datei-E / A-API bedeuten und den meisten vorhandenen Code unbrauchbar machen. Entweder das, oder Sie müssen auf Zehenspitzen um sie herumgehen und die alte API beibehalten. Erinnern Sie sich an PROGRA ~ 1.

Ich denke aus den oben genannten Gründen, dass die Zukunft zwar spezialisiertere Dateisysteme für spezielle Anwendungen beinhalten könnte, aber während die gegenwärtigen Desktop- und Laptop-PC-Architekturen überleben, bleiben wir beim weitgehend baumbasierten Dateisystem mit seinen fehlenden Metadaten und seine schrecklichen kleinen Erweiterungen.

Jetzt werde ich die Seite wechseln.

Weil es überall um uns herum ist, wissen wir nie wirklich zu schätzen, wie überwältigend mächtig die Baummetapher ist. Auf meiner Festplatte befinden sich mehrere hunderttausend Dateien. Wenn ich eine finden muss, dauert es selten länger als eine Minute, auch wenn ich sehr wenig über die Datei weiß. Stellen Sie sich nun dieselbe Aufgabe ohne Struktur vor, nur eine flache Liste von Namen, die endlos blättert.

Trotzdem sind alle Operationen unkompliziert, es gibt keine gruseligen Aktionen in einiger Entfernung, nichts, was mich dazu bringen würde, wach zu werden.

Eigentlich habe ich einmal einen Dokumentenspeicher mit umfangreichen Metadaten und einer DAG-basierten Hierarchie implementiert. (Es handelte sich nicht einmal um eine Freiform-DAG, es handelte sich ausschließlich um eine zweistufige Metastruktur und die Dokumente, bei denen es sich entweder um untergeordnete Elemente einer Sammlung der Stufe 1 oder einer Sammlung der Stufe 2 handeln könnte. Es ist also wirklich einfach.)

Offensichtlich musste die Anforderung, dass Dokumentnamen innerhalb einer Sammlung eindeutig sein sollten, bestehen bleiben.

Und dann begannen die Probleme zu fließen. Was passiert, wenn Sie eine Sammlung öffnen und den Namen des Dokuments in etwas ändern, das in einer anderen Sammlung, zu der das Dokument gehört, nicht übereinstimmt? Wir haben eine Fehlermeldung angezeigt, aber die Benutzer waren völlig verblüfft. (Dies sind dieselben Benutzer, die nach dieser Anforderung gefragt haben.)

Sie haben versucht, ein Dokument zu löschen, haben es jedoch nur aus der Sammlung entfernt. Es tauchte also immer noch in den Suchergebnissen auf. Wir haben es auch umgekehrt versucht, aber dann haben sie sich beschwert, dass sie ein Dokument aus Sammlung A gelöscht haben und es auf magische Weise aus Sammlung B verschwunden ist. Wir brauchten also sowohl einen "Unlink" - als auch einen harten Löschvorgang.

Irgendwann haben wir die Niederlage eingeräumt, zum Glück noch rechtzeitig.

Die zusätzlichen Suchfacetten, die die Metadaten ermöglichten, erwiesen sich jedoch als absolute Wohltat.

Um ehrlich zu sein, berühre ich kaum Metadaten meiner Dateien auf dem Mac. Ich denke, in den letzten 5 Jahren mit OSX (das Kommentare und so weiter unterstützt) habe ich Metadaten für vielleicht 2 Dateien verwendet. Nicht zu sagen, dass es eine schlechte Idee ist.

Ich bin mir nur nicht sicher, wie pragmatisch der Aufwand für das Markieren für mich ist.

Ich denke, die schönste Dateisystemfunktion, die ich kenne, wäre ein Dateisystem-Versionierungssystem, das partitionsübergreifend funktioniert. Es wurde auf VAXen in den 70er und frühen 80er Jahren gemacht, nicht sicher, warum es sich bei Unix und NTFS / Windows nicht durchsetzte.

Ich habe mit nicht hierarchischen Dateisystemen auf älteren Minis wie HP3000 und Encore / Gould gearbeitet. Sie hatten keine Verzeichnisse; Sie hatten eine Gruppe und ein Konto, und die Dateien wurden als " Gruppe . Konto . Datei " bezeichnet, z.

Nun, dies sind alte Systeme, bei denen die einzelnen Speicherplatzkontingente in den einzelnen Megabytes lagen. Es ist also nicht so, als ob Sie zu viele Ebenen zum Organisieren Ihrer Inhalte benötigen, aber aus der Sicht eines Benutzers und eines Programmierers sind hierarchische Systeme viel besser.

Ich sehe nicht, wo (zumindest einige) aktuelle Dateisysteme wirklich viel tun müssen, um Tags zu unterstützen. Wenn bekommen Sie es nach unten, umbauten Mittel etwas mehr als einige zusätzliche Daten zugeordnet Unterstützung mit einer Datei, ist aber nicht in den Strom der geschriebenen Bytes für diese Datei.

NTFS (um ein Beispiel zu wählen, das weit verbreitet ist ) kann das in Ordnung bringen: Für NTFS ist eine Datei nicht unbedingt ein einzelner Datenstrom von Bytes. Unter NTFS können Sie einem einzelnen Dateinamen eine beliebige Anzahl von Datenströmen zuordnen. Jede Datei hat einen (möglicherweise leeren) "primären Stream", der keinen Namen hat. Es kann jedoch auch eine beliebige Anzahl anderer Streams vorhanden sein, von denen jeder einen Namen haben muss. Auf diese Weise wäre es wirklich trivial , einer vorhandenen Datei einen Stream mit dem Namen (nur zum Beispiel) "Tags" hinzuzufügen und (offensichtlich genug) Ihre Tags in diesen Stream zu schreiben.

Danach kommt der etwas schwierigere Teil: Ihre Werkzeuge dazu zu bringen, die Tags zu verwenden, die Sie dort abgelegt haben. Idealerweise möchten Sie sie wahrscheinlich für eine schnelle Suche indizieren, damit Sie beispielsweise ein "virtuelles Verzeichnis" aller Dateien mit einem bestimmten Tag erstellen können.

Zumindest aus meiner Sicht hat das Dateisystem jedoch bereits das, was benötigt wird - es soll die Daten speichern und abrufen, und das kann es jetzt perfekt. Die Nutzung dieser Daten ist Aufgabe anderer Tools. Diese Tools sind derzeit nicht vorhanden, die Dateisysteminfrastruktur, die sie unterstützt, jedoch.

Wenn ich für einen Moment zynisch sein darf, würde ich sagen, dass es unvermeidlich war, dass diese Funktion von NTFS fast vollständig ignoriert und unbekannt bleibt. Schließlich ist es einfach zu bedienen und erfordert keine spezielle API oder etwas anderes. Sie können es sehr gut in vollständig portablem C, C ++ oder anderen Anwendungen verwenden, mit denen Sie einen beliebigen Dateinamen angeben können. Hier ist ein kurzer Code, der das Erstellen einer Datei mit einem AFS demonstriert:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

Und hier ist ein Code zum Lesen und Anzeigen der Tags:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Alles sehr einfach und unkompliziert. Beachten Sie, dass ich dort zwar nur ein triviales Datenpaket geschrieben habe, Sie ein AFS jedoch wie jede andere Datei behandeln können. In einer normalen Verzeichnisanzeige wird nur der primäre Stream angezeigt (z. B. entspricht die für die Datei angezeigte Größe der Größe des primären Streams). Wenn Sie sie jedoch anzeigen möchten, dir können Sie auch Informationen zu alternativen Streams anzeigen mit der /RFlagge. Beispielsweise sieht eine Auflistung für die oben erstellte Datei folgendermaßen aus:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes