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.