Cela existe-t-il: une manière standardisée de documenter une structure de système de fichiers

11

Au travail, je suis en charge de maintenir l'organisation d'un grand nombre de données variées sur un système de fichiers standard. Une partie de cela vient avec une classification sensible (par similitude, besoin, accès en lecture / écriture, etc.), mais la plus grande partie est en fait de le documenter: quels documents / fichiers / médias devraient aller où, ce qui ne devrait pas être dans ce répertoire, "pour quelque chose de légèrement différent, voir ../../other-dir", etc.

Pour le moment, j'ai documenté cela en utilisant un fichier readmeen clair dans chaque répertoire que je veux documenter. Si quelqu'un n'est pas sûr de ce qui doit se trouver dans un répertoire, il lit ce fichier.

Cela fonctionne bien, mais il semble étrange que j'aie cette solution personnalisée primitive à un problème que tout responsable d'une structure de répertoires non triviale doit rencontrer. Chaque entreprise que je connais, par exemple, a une sorte de système de fichiers partagé où la terminologie convenue pour la catégorisation est importante. D'après mon expérience, les gens n'ont qu'à apprendre ce qui est quoi par essais et erreurs et expérimentation.

Permettez-moi donc de proposer une meilleure solution, et j'espère que vous pourrez me dire si elle existe. N'importe quel répertoire sur n'importe quel système de fichiers peut avoir un fichier en clair masqué nommé .readme. Son contenu est un langage humain descriptif. Il utilise un balisage comme Markdown, avec un peu plus que des hyperliens en gras, en italique et (relatifs) vers d'autres répertoires. Maintenant, un navigateur de fichiers convenablement activé vérifiera un fichier nommé .readmechaque fois qu'il affiche un répertoire. S'il existe, son contenu est analysé et affiché dans un volet discret près du widget de chemin de répertoire. Il est possible de cliquer sur tous les liens qu'il contient et l'utilisateur sera redirigé vers le répertoire cible de ce lien.

Je pense que l'effort de mise en œuvre d'une telle norme rapporterait de nombreuses fois les gains de convivialité. Nous aurions, disons, des plugins pour Nautilus, Konqueror, etc. Il pourrait être utilisé pour afficher des informations de répertoire dans les listes de fichiers standard servies par les serveurs Web. Etc.

Alors, question: une telle chose existe-t-elle? Sinon, pourquoi pas? Les gens pensent-ils que c'est une idée valable?

jameshfisher
la source
Étant donné que vous mentionnez des améliorations du système de fichiers (ou des navigateurs de fichiers pour un système de fichiers spécifique), en particulier pour le code source, il convient également de mentionner la fonctionnalité bien nécessaire de la commande de fichiers . La plupart des systèmes de fichiers ont deux principaux types de classement: alphabétique et non trié. Mais qu'en est-il d'une commande spécifiée par l'utilisateur? Par exemple, dans le cas du code source, si vous avez 7 fichiers (classes, modules, composants) dans un dossier (module, package, composant parent), leur ordre "logique" n'est généralement pas le même que l'ordre alphabétique. Mais c'est plutôt l'ordre de leur "arbre de dépendance".
Sorin Postelnicu
Ainsi, en tant qu'additions standard aux systèmes de fichiers modernes, ces trois fonctionnalités devraient venir par défaut: 1) descriptions de fichiers, 2) classement de fichiers personnalisé dans un dossier et 3) étiquetage / étiquetage de fichiers. Il ne faut pas avoir besoin d'utiliser un CMS pour bénéficier de ces 3 fonctionnalités "basiques".
Sorin Postelnicu

Réponses:

5

Autant que je sache, il n'y a pas de norme. Voici quelques idées de mon expérience.

Installez-le, ne le changez jamais

C'est là que la plupart des entreprises échouent. Rien n'est pire qu'une structure de système de fichiers en constante évolution. S'il n'est pas possible de le maintenir constant, alors un système de fichiers pur est juste le mauvais conteneur pour organiser vos informations. Utilisez une base de données ou un système de gestion de contenu.

Utilisez des noms de répertoire descriptifs et cohérents

Personne n'a le temps de lire un .filingfichier ou autre chose. Si les noms de vos répertoires ne s'expliquent pas d'eux-mêmes, vous êtes probablement perdu de toute façon.

Rédiger une documentation pour votre structure de répertoires

Écrivez un document dans lequel vous expliquez le rôle de chaque répertoire. Donnez beaucoup d'exemples. Rendez-le accessible à tous ceux qui doivent travailler avec votre structure, mais ne croyez pas que quiconque le lira. Cela devrait ressembler davantage à une Bible pour vous. Il n'est pas facile de trouver un exemple pour un tel document, car il est évident que les entreprises ne les publient pas. Un exemple de logiciel open source est le Filesystem Hierarchy Standard .


Si cela semble un peu négatif, c'est le cas. Je n'ai jamais vu un référentiel non trivial basé sur un système de fichiers avec plus de cinq utilisateurs travailler à long terme dans la pratique. Le problème est que quelles que soient les catégories que vous configurerez, les gens auront des idées complètement différentes à leur sujet. Alors pour enfin répondre à vos questions:

Une telle chose existe-t-elle?

Non je ne pense pas.

Sinon, pourquoi pas?

À mon avis: pour une petite hiérarchie statique avec quelques utilisateurs, c'est exagéré. Pour une grande hiérarchie changeante avec de nombreux utilisateurs, cela ne fonctionnera pas car l'idée de catégories (= répertoires, dossier) ne se met pas à l'échelle.

Les gens pensent-ils que c'est une idée valable?

Hm, c'est une idée intéressante. Pour voir si les gens vont l'utiliser, quelqu'un doit le mettre en œuvre. Au lieu d'un .filingfichier, vous pouvez stocker ces informations dans un autre flux de données (oui, les dossiers peuvent également avoir des ADS). Vous pouvez utiliser des attributs étendus sous Linux et OSX. Le plus gros problème serait probablement de patcher les navigateurs de fichiers.

Ludwig Weinzierl
la source
1
"Rien n'est pire qu'une structure de système de fichiers en constante évolution", à l'exception de celle qui refuse résolument de changer même lorsque la structure n'a plus de sens.
jameshfisher
1
"Utiliser des noms de répertoire descriptifs et cohérents" - absolument nécessaire, oui. Malheureusement, il y a un conflit entre la descriptivité et la brièveté - personne ne veut taper un chemin vers un fichier dans / srv / all-hierarchical-data / accessible-only-by-office-and-admin / letters-but-not-public -avis / académique-année-2009 / ... et ainsi de suite.
jameshfisher
"Rédigez une documentation pour votre structure de répertoire" - aussi une excellente idée. C'est essentiellement ce que je suggère; juste que la documentation serait distribuée plutôt que monolithique.
jameshfisher
"l'idée des catégories (= répertoires, dossier) n'est pas évolutive" - ​​true-ish, sauf parfois juste. Par exemple, de grandes arborescences de sources logicielles ( git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree ).
jameshfisher
"Au lieu d'un .filingfichier, vous pouvez stocker ces informations dans un autre flux de données (oui, les dossiers peuvent également avoir des ADS). Vous pouvez utiliser des attributs étendus sur Linux et OSX." Possible, j'imagine, mais diminue la portabilité et la transparence qui, je pense, sont si importantes. Et si je veux tout placer dans un dépôt git? Les fichiers en texte clair sont utilisés pour la configuration spécifique au répertoire (par exemple htaccess), alors pourquoi pas la documentation aussi?
jameshfisher
2

le wasabi vaut le coup. À la racine de votre projet, la source en texte brut servira de solide aperçu du projet et vous pouvez lancer le même document dans un navigateur pour des résultats plus sophistiqués.

Certes, ce n'est pas une solution basée sur un système de fichiers, mais jusqu'à ce que tous les systèmes de fichiers autour prennent en charge quelque chose de commun, le wasabi (ou votre propre implémentation de celui-ci) pourrait bien être la meilleure option.

user3276552
la source
1

Votre idée a un certain mérite, mais je crains que lorsque vous avez besoin de quelque chose comme ça, cela signifie vraiment que vous avez besoin de quelque chose de plus structuré. C'est à dire un CMS, peut-être juste un léger, mais certainement quelque chose de plus qu'un simple fichier textuel.

Surtout si vous souhaitez restreindre l'écriture (ou même l'accès) à des documents spécifiques (et donc à leurs dossiers contenant) dans un sous-ensemble de votre base d'utilisateurs.

Vous ne spécifiez pas votre système d'exploitation, mais il existe d'excellents produits (gratuits) comme alfresco qui pourraient peut-être vous servir mieux que votre configuration actuelle.

p.marino
la source
J'ai essayé divers CMS, mais j'ai constaté que la portabilité, la simplicité et la transparence sont des coûts énormes à payer par rapport au CMS le plus vénérable du marché: l'arborescence des répertoires. La plupart des données que j'ai eu à gérer pouvaient s'inscrire dans une hiérarchie. En dernier recours, il existe des liens symboliques. Et la structure de répertoires est parfois la seule solution: par exemple dans le développement de logiciels, le code source est, à la base, une arborescence de répertoires. (Documenter des répertoires comme celui-ci signifie généralement s'en tenir à un schéma rigide et cryptique, qui finit par tomber en panne. Je pense que ma solution pourrait également aider ici.)
jameshfisher
Comme je l'ai dit, votre idée a du mérite, mais je pense, comme l'auteur de l'autre affiche, que cela ne peut pas aller au-delà d'un niveau donné. Vous mentionnez le code source, mais c'est un cas très spécialisé - et lorsque vous y ajoutez du code, vous ne regardez pas dans les répertoires existants pour trouver où il devrait "tenir". Un CMS vous donne généralement la possibilité de baliser des trucs pour que vous ayez des "répertoires" (dossiers, espaces, pages) qui fonctionnent comme votre solution, PLUS un système de balisage permettant aux gens de trouver des trucs sans avoir à chercher le "bon" répertoire. C'est plus flexible que les liens symboliques et moins sujet aux erreurs, à mon humble avis.
p.marino
1

Voici une idée. Écrivez un script qui pose à l'utilisateur diverses questions sur le fichier et / ou effectuez une correspondance dans le contenu du fichier lui-même, puis recommande l'emplacement où placer le fichier ou le place lui-même. Le script peut être aussi simple ou complexe que vous le souhaitez.

Le script agit comme un système de gestion de fichiers, un système d'aide à la décision et une documentation évolutive de la hiérarchie du système de fichiers. La norme de hiérarchie du système de fichiers Linux est un peu un mythe si vous y réfléchissez, car il existe une très grande différence entre les distributions. Cependant, la plupart des utilisateurs Linux / Unix n'ont pas à se renseigner sur la hiérarchie du système de fichiers eux-mêmes car il existe divers logiciels installés dans le système qui gèrent la hiérarchie de manière standardisée (gestionnaire de packages, outil de configuration, etc.). Divers cadres d'application créent également des scripts pour gérer ses répertoires, par exemple, django a des commandes de gestion pour créer un nouveau projet, ou un nouveau module d'application, ou des fichiers de migration de squash, etc.

Cela présente l'avantage supplémentaire que le script peut créer divers liens symboliques si le fichier doit être recherché de plusieurs manières, par exemple un index basé sur l'auteur du fichier ou la date de création ou quelque règle métier que vous ayez. Vous pouvez simuler le marquage avec des liens symboliques. Une balise est un simple lien symbolique d'un tagsrépertoire, donc tags/mytag/myfilepeut être un lien symbolique vers actual/myfile.

De plus, il sera également possible de modifier la structure de la hiérarchie du système de fichiers sans changer l'interface utilisateur.

Un système de fichiers est une base de données. Pas une base de données relationnelle, mais une base de données hiérarchique. Pensez-y comme gérer une base de données, vous ne voulez pas vraiment obliger les gens à apprendre la structure relationnelle, mais vous voulez plutôt que l'application se présente à l'utilisateur comme diverses tâches qu'il doit faire (par exemple, faites-vous un mensuel Rapport XYZ, génial, puis placez-le dans ce dossier et créez ce lien symbolique, puis vous devrez modifier un autre fichier pour enregistrer que vous avez fait le rapport pour ce mois, etc.).

Lie Ryan
la source