Comment avons-nous été confrontés au système de fichiers (hiérarchique) en tant que structure de données de base?

Je suis autodidacte et je n'ai pas de diplôme CS. Plus j'en apprends sur la structure des données, plus je me demande, de nos jours, comment sommes-nous encore confrontés au système de fichiers, aux répertoires et aux fichiers, en tant que structure de stockage de données de base sur le système d'exploitation?

J'en comprends la simplicité, mais il semble aujourd'hui qu'il pourrait y avoir plus d'options disponibles nativement. Pour autant que je sache, le seul projet pour améliorer les fonctionnalités de base du système de fichiers était ReiserFS, où vous pouviez savoir quelle ligne d'un fichier avait été modifiée par qui et quand.

Par exemple, si je pouvais avoir un balisage natif pour les fichiers, où je pourrais baliser des images, des diagrammes, des documents de traitement de texte, un référentiel de code entier, le tout comme appartenant à un seul projet, cela me serait vraiment utile. Comme je suis coincé dans le paradigme du système de fichiers, je sais que je pourrais mettre tous ceux-ci dans un seul dossier / répertoire, mais que faire s'ils existent déjà dans des répertoires disparates et qu'ils doivent y rester? Je sais qu'il existe des programmes qui peuvent le faire, mais pourquoi ne sont-ils pas sur le système de fichiers?

Quelque chose qui serait bien d'avoir, c'est une sorte de fonctionnalité relationnelle dans le système de fichiers, comme vous obtenez avec les SGBDR. Je comprends que cela devait faire partie de Vista / 7, mais cela est également tombé de la liste des fonctionnalités.

Bien sûr, n'importe quel programme peut stocker un fichier binaire et avoir la structure de données qu'il souhaite, par pourquoi le système d'exploitation ne pourrait-il pas proposer des moyens plus complexes de stockage de données, au-delà de la simple hiérarchie du système de fichiers?

Commencez par ceci: http://en.wikipedia.org/wiki/Unix_File_System

Lisez ceci: http://www.unix.org/what_is_unix/history_timeline.html

Lisez ensuite ceci: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Il y a une réponse simple à "pourquoi le système d'exploitation ne pourrait-il pas offrir des moyens plus complexes de stockage de données, au-delà de la simple hiérarchie du système de fichiers?"

Parce que c'est trop pour le système d'exploitation.

C'est à cela que servent les bibliothèques et les packages d'applications.

Oracle, par exemple, vous vendra un ensemble de fonctionnalités de type système de fichiers que vous gérez avec l'ensemble d'outils Oracle.

Python utilise la bibliothèque DBM pour créer des structures de stockage sur disque très sophistiquées.

CouchDB et Mongo (et d'autres) sont des structures de stockage très sophistiquées qui offrent des fonctionnalités de type base de données.

Le fait est que le système d'exploitation doit faire le minimum et que tout est un module complémentaire.

La réponse courte est: les gens ordinaires comprennent le système de fichiers. Cela leur rappelle un classeur. Pensez aux pages Web et même aux applications Fat, pourquoi pensez-vous qu'elles Tabssont si populaires? Les gens peuvent s'identifier à eux et les comprendre rapidement.

Imagerie essayant d'apprendre à grand-mère à rechercher une base de données pour un fichier en fonction des balises de propriété. Avec le système de fichiers, grand - mère sait que le fichier est simplement là où elle l'a mis .

Même avec WinFS, je ne pense pas que MS allait se débarrasser de l'apparence du système de fichiers.

Il y a un peu de vérité dans chaque réponse, mais je ne pense pas que ce soit toute la vérité.

Ce que vous listez sont principalement des fonctionnalités qui sont cruellement manquées chaque jour par les utilisateurs et les développeurs.

Les gens ne comprennent pas plus le système de fichiers basé sur l'arborescence qu'ils ne comprendraient un système basé sur DAG.

Et il n'y a absolument aucune excuse pour les appendices pathétiques des noms de fichiers appelés extensions. Ils sont non seulement totalement inadaptés à leur finalité (identification du type de fichier) mais aussi une source de nuisance infinie pour les utilisateurs.

La raison pour laquelle nous les utilisons toujours est un mélange d'une attitude "qui fera l'affaire" et du réel besoin de maintenir la compatibilité avec le code plus ancien. Une nouvelle approche du stockage des fichiers signifierait un changement radical dans l'API d'E / S de fichiers de base, rendant la plupart des codes existants inutiles. Soit cela, soit vous devez les mettre sur la pointe des pieds, en conservant l'ancienne API. N'oubliez pas PROGRA ~ 1.

Je pense que pour les raisons ci-dessus, bien que l'avenir puisse contenir des systèmes de fichiers plus spécialisés pour des applications spéciales, mais bien que les architectures de PC de bureau et portables d'aujourd'hui survivent, nous sommes coincés avec le système de fichiers en grande partie arborescent avec son manque de métadonnées et ses horribles petites extensions.

Maintenant, je vais changer de camp.

Parce que tout est autour de nous, nous n'apprécions jamais vraiment à quel point la métaphore de l'arbre est époustouflante. Sur mon disque dur, j'ai plusieurs centaines de milliers de fichiers. Si je dois en trouver un, cela prend rarement plus d'une minute, même si je connais très peu le dossier. Imaginez maintenant la même tâche sans aucune structure, juste une liste plate de noms, défilant sans fin.

Pourtant, toutes les opérations sont simples, il n'y a aucune action effrayante à distance, rien qui me ferait aller wtf.

En fait, j'ai implémenté une fois un magasin de documents avec des métadonnées riches et une hiérarchie basée sur DAG. (Ce n'était même pas un DAG de forme libre, c'était strictement une métastructure à deux niveaux et les documents, qui pouvaient être des enfants d'une collection de niveau 1 ou de niveau 2. Donc c'est vraiment simple.)

De toute évidence, l'exigence selon laquelle les noms des documents doivent être uniques dans une collection doit rester.

Et puis les problèmes ont commencé à couler. Que se passe-t-il si vous ouvrez une collection et changez le nom du document en quelque chose qui se heurte dans une autre collection à laquelle le document appartient également? Nous avons affiché un message d'erreur mais les utilisateurs étaient complètement déconcertés. (Ce sont les mêmes utilisateurs qui avaient demandé cette exigence.)

Ils ont essayé de supprimer un document, mais tout ce qu'il a fait a été de le retirer de la collection. Il apparaît donc toujours dans les résultats de recherche. Nous l'avons également essayé dans l'autre sens, mais ils se plaignaient ensuite d'avoir supprimé un document de la collection A et qu'il avait disparu comme par magie de la collection B. Nous avions donc besoin à la fois d'une opération de «dissociation» et d'une suppression matérielle.

Finalement, nous avons concédé la défaite, heureusement encore à temps.

Les facettes de recherche supplémentaires rendues possibles par les métadonnées ont cependant été un régal absolu.

Pour être honnête, je touche à peine les métadonnées de mes fichiers sur Mac. Je pense qu'au cours des 5 dernières années d'utilisation d'OSX (qui prend en charge les commentaires, etc.), j'ai utilisé des métadonnées sur peut-être 2 fichiers. Ne dis pas que c'est une mauvaise idée.

Je ne sais tout simplement pas comment les frais généraux de marquage sont pragmatiques pour moi.

Je pense que la plus belle fonctionnalité de système de fichiers que je connaisse serait un système de version au niveau du système de fichiers ... qui fonctionne entre les partitions. Cela a été fait sur VAXen dans les années 70 et au début des années 80, je ne sais pas pourquoi cela n'a pas fonctionné avec Unix et NTFS / Windows.

J'ai travaillé avec des systèmes de fichiers non hiérarchiques sur des minis plus anciens comme HP3000 et Encore / Gould. Vous n'aviez pas de répertoires; vous aviez un groupe et un compte, et les fichiers étaient nommés " groupe . compte . fichier ", comme "users.jbode.myfile1", "dev.jbode.main", etc.

Maintenant, ce sont d' anciens systèmes, où les quotas d'espace disque individuels étaient dans le seul mégaoctet, donc ce n'est pas comme si vous aviez besoin de trop de niveaux pour organiser vos trucs, mais du point de vue d'un utilisateur et d'un programmeur, les systèmes hiérarchiques sont beaucoup plus agréables.

Je ne vois pas où (au moins certains) les systèmes de fichiers actuels ont vraiment besoin de faire beaucoup [Edit: n'importe quoi, pour être honnête] pour supporter les balises. Lorsque vous y arrivez, la prise en charge des balises signifie un peu plus que certaines données supplémentaires associées à un fichier, mais n'est pas écrite dans le flux d'octets de ce fichier.

NTFS (pour choisir un exemple qui est largement utilisé) peut très bien le faire: en ce qui concerne NTFS, un fichier n'est pas nécessairement un seul flux d'octets. Sur NTFS, vous pouvez associer un nombre arbitraire de flux de données à un seul nom de fichier. Chaque fichier a un "flux primaire" (éventuellement vide) qui n'a pas de nom. Cependant, il peut également avoir un nombre arbitraire d'autres flux, dont chacun doit avoir un nom. En utilisant cela, il serait vraiment trivial d'ajouter un flux nommé (juste par exemple) "balises" à un fichier existant, et (évidemment assez) d'écrire vos balises dans ce flux.

Après cela vient la partie un peu plus difficile: obtenir vos outils pour utiliser les balises que vous y mettez. Idéalement, vous voudriez probablement les indexer pour une recherche rapide, donc vous pourriez faire des choses comme créer un "répertoire virtuel" de tous les fichiers avec une balise spécifique.

Au moins de mon point de vue, le système de fichiers a déjà ce qu'il faut - il est censé stocker et récupérer les données, et il peut parfaitement le faire en ce moment. L'utilisation de ces données est le travail d'autres outils. Ces outils n'existent pas actuellement, mais l'infrastructure du système de fichiers pour les prendre en charge existe.

Si je suis autorisé à être cynique pendant un moment, je dirais qu'il était inévitable que cette fonctionnalité de NTFS resterait presque complètement ignorée et inconnue. Après tout, il est simple à utiliser et ne nécessite aucune API spéciale ni rien d'autre. Vous pouvez l'utiliser très bien en C, C ++ complètement portable ou tout autre élément qui vous permettra de spécifier un nom de fichier arbitraire. Voici un petit bout de code pour illustrer la création d'un fichier avec un AFS:

#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;
}

Et, voici du code pour lire et afficher les balises:

#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;
}

Tout est très simple et facile. Notez que même si je n'y ai écrit qu'un petit peu de données, vous pouvez traiter un AFS comme n'importe quel autre fichier - tous les "trucs" habituels fonctionnent comme n'importe quoi d'autre. Dans un affichage de répertoire normal, tout ce qui apparaîtra est le flux principal (par exemple, la taille indiquée pour le fichier sera la taille du flux principal), mais si vous voulez le voir, il dir peut également afficher des informations sur les flux alternatifs avec le /Rdrapeau. Par exemple, une liste du fichier créé ci-dessus ressemble à ceci:

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