Ce document spécifie une structure de système de fichiers standard pour les systèmes Linux, comprenant l'emplacement des fichiers et répertoires, ainsi que le contenu de certains fichiers système.
Le système de fichiers standard a été élaboré pour être utilisé par les développeurs de distributions Linux, les développeurs de packages, et les implémenteurs du système. Cependant, il se propose d'abord d'être une référence et n'est pas un tutoriel sur la manière d'administrer un système de fichiers Linux ou une hiérarchie de répertoires.
Voici quelques uns des problèmes fondamentaux qui ont motivé de prime abord cet effort de standardisation :
* Il n'y a aucune structure de répertoire bien acceptée pour Linux. À la place, il y en a eu beaucoup de différentes, chacune incompatible avec l'autre.
* Les hiérarchies de systèmes de fichiers les plus couramment utilisées n'étaient pas bien structurées et différaient sans motif apparent des "modèles" de structure de répertoire les plus modernes (tels que System V, BSD, SunOS, et autres).
* Le système de fichiers était peu familier et peu confortable pour les utilisateurs et administrateurs UNIX expérimentés qui ont des connaissances sur des systèmes UNIX plus traditionnels.
* L'absence de régularité était aussi déconcertante pour les débutants sur Linux, surtout pour ceux n'ayant pas d'expérience préalable en UNIX.
* Toutes les incompatibilités entre les distributions Linux de base et d'autres packages logiciels étaient résolues en général par des méthodes très peu attrayantes.
* Et surtout, les liens symboliques étaient utilisés bien trop souvent dans le système de fichiers afin de résoudre les problèmes. (Cependant, il y a des fois où les liens symboliques sont nécessaires pour assurer une compatibilité ascendante ou pour permettre à des systèmes spécifiques d'avoir une structure de système de fichiers individuelle.)
Des différences d'opinion sont soulevées dans tout effort de standardisation. Le besoin de consensus et la pratique courante à l'intérieur de la communauté Linux devrait surpasser ces différences.
Cette norme de système de fichiers a été développée tout d'abord à l'intérieur de la liste de distribution FSSTND et avant, sur le canal FSSTND de la liste de distribution Linux-activists. Un grand nombre de développeurs Linux, de programmeurs Linux renommés, d'administrateurs système et d'utilisateurs ont envoyé des demandes et commentaires. Les volontaires qui ont contribué intensément à cette norme sont listés à la fin de ce document. Cette norme représente la vue consensuelle de ceux-ci et d'autres collaborateurs.
Cette norme cherche à approcher ces problèmes en décrivant une structure de système de fichiers bien faite, dont nous espérons que la communauté Linux la suivra volontairement. Bien que cette norme soit plus exhaustive et complète que toute autre tentative précédente de standardisation, elle ne sera probablement jamais vraiment terminée. Les besoins de la communauté Linux changeront continuellement en relation avec les technologies apparaissantes. Il est aussi possible que de meilleures solutions aux problèmes auxquels nous faisons face seront découvertes ou que nos solutions ne soient plus les meilleures possibles. Pour ces raisons, le groupe FSSTND prévoit de diffuser des ébauches supplémentaires en supplément des mises à jour périodiques de ce document.
Les commentaires se rapportant à cette norme sont les bienvenus parmi le groupe FSSTND. Tout commentaire ou suggestion de changement doit être adressé au coordinateur FSSTND, ou si vous préférez, à n'importe lequel des contributeurs listés. Les commentaires d'ordre typographique ou grammatical doivent être envoyés au coordinateur FSSTND.
Il y a aussi une FAQ, maintenue par Ian McCloghrie, qui répond à certaines des questions les plus couramment posées au sujet de cette norme. Si vous désirez implémenter la FSSTND ou si vous avez des questions, veuillez lire la FAQ FSSTND d'abord. Celle-ci est disponible par FTP anonyme à tsx-11.mit.edu dans /pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ.
S'il vous plaît n'envoyez pas de courrier électronique à la liste de distribution sans avoir contacté d'abord le coordinateur FSSTND ou l'un des contributeurs listés. Les messages non conformes ne seront pas bien reçus sur la liste de distribution.
Certaines questions sur la manière d'interpréter certains objets de ce document peuvent se poser de temps à autre. Si vous avez besoin d'une clarification, veuillez contacter le coordinateur FSSTND. Puisque cette norme représente le consensus de nombreux participants, il est important d'être certain que toute interprétation représente aussi l'opinion collective. Pour cette raison, il peut ne pas être possible de fournir une réponse immédiate sauf si la demande a déjà fait l'objet d'une discussion préalable.
Le coordinateur FSSTND est Daniel Quinlan <Daniel.Quinlan@linux.org>
Naturellement, pendant la standardisation de la structure du système de fichiers Linux, il y a eu des problèmes spécifiques que nous avons cherché à corriger. Voici quelques uns des plus évidents et des plus grands :
* Les répertoires de binaires principaux, /bin et /usr/bin, n'ont pas de frontières bien définies entre eux. Par suite, la répartition des binaires entre ces deux répertoires diffère beaucoup entre les distributions Linux.
* Inclure à fois les binaires et les fichiers de configuration dans /etc rend ce répertoire plus confus et plus difficile à maintenir, à la fois pour les utilisateurs inexpérimentés et pour les administrateurs système (surtout ceux qui ont des gros systèmes).
* La limite entre un fichier de configuration à l'échelle d'un site et un autre à l'échelle d'une machine seule est difficile à établir.
* La plupart des mises en oeuvre courantes de /usr ne peuvent être montées en lecture seule parce qu'elles contiennent des fichiers de variables et des répertoires sur lesquels on a besoin d'écrire.
* Dans un environnement en réseau, il est souhaitable de servir les logiciels aux stations de travail par NFS. De tels systèmes de fichiers peuvent avoir besoin d'être montés en lecture seule afin que des accidents ou des mauvais esprits sur une station de travail ne puissent endommager les fichiers sur le serveur. Ceci requiert l'identification et la séparation des fichiers sur lesquels une machine doit écrire et des fichiers spécifiques à une seule machine.
* Les structures de système de fichiers Linux courantes n'étaient en général pas bien faites pour les installations en réseau qui peuvent nécessiter des composants en lecture seule à l'intérieur du système de fichiers (principalement dans la hiérarchie /usr) ou qui comportent des stations de travail sans disques.
Alors qu'il y a quelques uns des principaux problèmes auxquels nous avons fait face, il y a eu de nombreux problèmes supplémentaires qui demandaient à être résolus. Cette norme essaie de s'occuper de beaucoup de ces autres problèmes, mais quelque chose a peut-être été oublié. Si vous voulez porter quelque chose à notre attention, veuillez noter que certaines choses ont longtemps été débattues, mais n'ont pas été incluses dans la norme.
En essayant de résoudre les problèmes ci-dessus, plusieurs objectifs ont été identifiés qui demandaient à être résolus en supplément des problèmes plus techniques. Ces buts comprennent la correction des problèmes de première importance ainsi que la validation de cette norme.
* Résoudre les problèmes listés ci-dessus tout en limitant les difficultés de transition en s'éloignant des normes de facto précédentes.
* Obtenir l'approbation des distributeurs, développeurs et autres gens importants dans la communauté Linux, et aussi les encourager à nous donner leurs suggestions.
* Fournir une norme que la communauté Linux entière choisira de suivre parce qu'elle résout les problèmes ci-dessus et fournit la structure la plus raisonnable pour les systèmes de fichiers des installations Linux.
Certains de ces objectifs ont deja été atteints en totalité ou partiellement grâce à la distribution limitée d'une ébauche anticipée à tout développeur qui la demandait.
Le message originel qui a motivé cet effort de restructurer le système de fichiers Linux a été écrit par Olaf Kirsh <okir@monad.swb.de> le 2 août 1993, au canal NORMAL de la liste de distribution Linux-activists.
Peu de temps après, il a été décidé que la meilleure manière possible d'accomplir la restructuration nécessaire du système de fichiers Linux serait de créer une liste de distribution dans le but de développer une norme consensuelle.
Après une discussion exhaustive, avec étonnamment peu de flammes, une ébauche préliminaire fut écrite. Avec l'aide de plusieurs personnes consacrées, l'ébauche fut terminée et l'ébauche résultante soumise au canal FSSTND pour une discussion supplémentaire. La première ébauche fut soumise au canal le 18 septembre 1993 par Daniel Quinlan.
Alors que la discussion se poursuivait et que les ébauches préliminaires des recommandations FSSTND étaient développées plus avant, des contacts furent établis avec les distributeurs Linux accessibles qui ont alors offert leur demandes et leur support à notre effort. Beaucoup de développeurs Linux s'accordèrent sur le fait que cet effort de standardisation valait la peine et l'ont supporté.
Voici quelques uns des développeurs qui tendent à suivre la norme FSSTND, en partie ou complètement, listés par ordre alphabétique :
* ATIM Linux/PRO
Fred N. van Kempen et al. <waltje@infomagic.com>
* BOGUS Linux
Rik Faith, Kevin E. Martin, et Doug L. Hoffman <linux-bogus@cs.unc.edu>
* Debian Linux
Ian A. Murdock <imurdock@debian.org>
* LILO boot loader
Werner Almesberger <almesber@nessie.cs.id.ethz.ch>
* MCC Interim Linux
Owen Le Blanc <LeBlanc@mcc.ac.uk>
* Red Hat Software Linux (RHS Linux)
Marc Ewing <marc@redhat.com>
* Slackware Linux
Patrick J. Volkerding <volkerdi@mhd1.moorhead.msus.edu>
* TAMU Linux
Dave Safford <dave.safford@net.tamu.edu>
* util-linux package
Rik Faith <faith@cs.unc.edu>
* Yggdrasil Plug-and-Play Linux
Adam J. Richter <adam@yggdrasil.com>
Cette section définit les significations des termes "conforme" et "compatible" en ce qui concerne cette norme, et de conformité et compatibilité "partielle".
Une "implémentation" fait référence ici à une distribution, un système installé, un programme, un package (ou tout morceau similaire de programme ou de données) ou tout composant de ceux-ci.
Une implémentation est totalement conforme avec cette norme si chaque exigence de cette norme est satisfaite. Chaque fichier ou répertoire faisant partie de l'implémentation doit être situé comme spécifié dans ce document. Si le contenu d'un fichier est décrit ici, le contenu réel doit correspondre à la description. L'implémentation doit aussi essayer de trouver tous les fichiers et répertoires (externes à elle-même) tout d'abord et exclusivement aux endroits spécifiés dans cette norme.
Une implémentation est totalement compatible avec cette norme si chaque fichier ou répertoire qu'elle comporte peut être trouvé en regardant dans les endroits spécifiés ici et seront trouvés avec les contenus spécifiés ici, même si ce n'est pas la position primaire ou physique du fichier ou du répertoire en question. L'implémentation doit, quand elle essaie de trouver un fichier ou un répertoire qui n'en fait pas partie, le faire aux endroits spécifiés par cette norme, bien qu'elle puisse aussi essayer de les trouver à d'autres endroits (non standards).
Une implémentation est partiellement conforme ou compatible si elle est conforme à, ou est compatible avec une partie significative de ce document.
La conformité ou la compatibilité partielle n'est faite que pour s'appliquer aux distributions et non aux programmes séparés. Il faut reconnaître que l'expression "Une partie significative" est subjective, et dans les cas limites, la personne concernée devrait contacter le coordinateur FSSTND. Il est envisagé que des variations seront tolérées dans les cas limites.
Afin de se définir comme partiellement conforme à FSSTND ou partiellement compatible avec FSSTND, une implémentation doit fournir une liste de tous les endroits auxquels elle et le document FSSTND diffèrent en plus d'une explication brève de la raison de cette différence. Cette liste sera fournie avec l'implémentation en question, et aussi mise à disposition de la liste de distribution FSSTND ou du coordinateur FSSTND.
Les termes "doit", "devrait", "contient", "est" et ainsi de suite doivent être lus comme des exigences pour la conformité ou la compatibilité.
Notez qu'une implémentation n'a pas besoin de contenir tous les fichiers et répertoires spécifiés dans cette norme pour être conforme ou compatible. Il est simplement nécessaire que les fichiers qu'elle contient soient situés correctement. Par exemple, si le système de fichiers ext2 n'est pas supporté par une distribution, les outils ext2 n'ont pas besoin d'être inclus, même s'ils sont mentionnés explicitement dans la section sur /sbin.
De plus, certaines parties de ce document sont optionnelles. Dans ce cas, ceci sera dit explicitement, ou indiqué à l'aide d'un ou plusieurs "peut", "recommende" ou "suggère". Les objets marqués comme optionnels n'ont pas de portée sur la conformité ou la compatibilité d'une implémentation ; ce sont des suggestions faites pour encourager la pratique courante, mais peuvent être situées n'importe où au choix de l'implémenteur.
