La barre oblique (/) fait-elle partie du nom du répertoire racine Linux?

46

La barre oblique ( /) fait-elle vraiment partie du nom du répertoire racine Linux? Ou est-ce juste un symbole pour cela?

Qu'en est-il /etcet ainsi de suite?

Mise à jour

Suppose /dev/sda2est le périphérique bloc d'un répertoire racine Linux.

$ sudo debugfs / dev / sda2
debugfs 1.44.1 (24-mars-2018)
debugfs:   pwd
[pwd] INODE: 2 CHEMIN: /
[racine] INODE: 2 CHEMIN: /
debugfs:   stat /
Inode: 2    Type: Répertoire     Mode: 0755 Drapeaux: 0x80000
Génération: 0 Version: 0x00000000: 00000077
Utilisateur: 0 Groupe: 0 Projet: 0 Taille: 4096
Fichier ACL: 0
Liens: 25 Nombre de blocs: 8
Fragment: Adresse: 0 Numéro: 0 Taille: 0
 ctime: 0x5b13c9f1: 3f017990 - dim. 3 juin 15:28:57 2018
 atime: 0x5b13ca0f: 3b3ee380 - dim 3 juin 15:29:27 2018
 mtime: 0x5b13c9f1: 3f017990 - dim. 3 juin 15:28:57 2018
crtime: 0x5aad1843: 00000000 - sam. mars 17 16:59:39 2018
Taille des champs d'inode supplémentaires: 32
EXTENTS:
(0): 9249

Il y a donc un répertoire, l’inode n ° 2, mais il n’a pas de nom.

linux filesystems filenames fhs mlibre
la source
1
En ce qui concerne votre mise à jour récente montrant une debugfssortie. Pouvez-vous préciser en quoi cela change la question?
Kusalananda
Ce n'est pas. Je voulais juste compléter les réponses. mais je ne voulais pas en ajouter un autre. donc je l'ai mis à jour. si vous pouvez mettre cette ligne dans votre réponse, vous les supprimerez
mlibre

Réponses:

61

La norme POSIX.1-2008 dit

Un chemin composé d'un seul /doit être résolu dans le répertoire racine du processus. Un chemin d'accès nul ne doit pas être résolu avec succès.

La norme établit en outre une distinction entre les noms de fichiers et les noms de chemins . /est le chemin d'accès au chemin du répertoire racine. Le nom du répertoire est "le répertoire racine", mais dans le système de fichiers, il n'a pas de nom, il n'a pas de nom de fichier. S'il avait un nom de fichier, ce nom serait une entrée de répertoire dans le répertoire situé au-dessus du répertoire racine. Ce répertoire n'existe pas.

Le caractère /ne peut jamais faire partie d'un nom de fichier car c'est le séparateur de chemin.

Pour plus de clarté: ce /n’est pas le nom du répertoire racine, mais son chemin , son chemin .

/etcest un autre chemin. C'est le nom du chemin absolu du etcrépertoire. Le nom du répertoire sur ce chemin est etc(son nom de fichier est etc).

/usr/local/bin/curlest le chemin du curlfichier exécutable de la même manière que /etcle chemin du etcrépertoire.

Kusalananda
la source
"S'il avait un nom de fichier, ce nom serait une entrée de répertoire dans le répertoire situé au-dessus du répertoire racine". Ce serait techniquement deux: un numéro d'inode et un nom (qui, comme nous le savons, est l'inode 2). Il est également intéressant de noter que /..pointe vers /, et /a une entrée de répertoire pour lui-même - c'est le bon vieux /.; toutes ces 3 choses pointent vers le même inode - 2.
Sergiy Kolodyazhnyy
@SergiyKolodyazhnyy Techniquement , le répertoire racine est "par processus", ce qui est important dans les environnements chroot. Dans un chroot, le numéro d'inode du répertoire racine ne serait pas un numéro particulier (il s'agirait du numéro d'inode de la racine du chroot). De plus, je pense que le nombre 2 (dans les situations non chrootées) dépend du système de fichiers utilisé.
Kusalananda
J'ai aussi remarqué que cela /est défini en termes de racine par processus, mais je ne savais pas que l'inode chrootn'est pas nécessairement 2. Fait très intéressant. Cela soulève également la question de savoir quel est le /répertoire des processus du noyau privilégiés. Est-ce que cela signifie que seuls les processus de l'espace utilisateur /sont associés?
Sergiy Kolodyazhnyy le
37

slash est un séparateur ; Les noms de répertoire n'incluent pas de séparateurs, mais les noms de chemins complets incluent les séparateurs.

Donc, le "niveau racine" / n'a pas de nom . Sur la plupart des systèmes de type Unix, ceci est traité comme un cas spécial comme .et ..(bien que bien sûr, il n'y a pas de différence entre les deux au niveau racine).

La nomenclature peut différer. POSIX.1-2017, par exemple, répertorie certaines définitions couramment utilisées :

  • 3.2 Chemin absolu

    Un chemin commençant par un seul ou plus de deux <slash>caractères; voir aussi Pathname .

  • 3.271 chemin

    Une chaîne utilisée pour identifier un fichier. Dans le contexte de POSIX.1-2008, un chemin peut être limité à {PATH_MAX} octets, y compris l'octet nul de fin. Il comporte des <slash>caractères de début facultatifs , suivis de zéro ou de plusieurs noms de fichiers séparés par des <slash>caractères. Un chemin peut éventuellement contenir un ou plusieurs <slash>caractères de fin . Plusieurs <slash>caractères successifs sont considérés comme identiques <slash>, à l’exception du cas de exactement deux <slash>caractères d’avant.

    Remarque: Si un chemin ne contient que des octets correspondant aux caractères du jeu de caractères du nom de fichier portable (voir Jeu de caractères du nom de fichier portable ), des <slash>caractères et un seul caractère de fin.<NUL>caractère, le chemin sera utilisable en tant que chaîne de caractères dans tous les paramètres régionaux pris en charge; sinon, le nom du chemin pourrait n'être qu'une chaîne (plutôt qu'une chaîne de caractères). De plus, comme l'encodage sur un seul octet du <slash>caractère doit être identique dans tous les paramètres régionaux et ne pas se produire dans un caractère multi-octets, les références à un <slash>caractère dans un chemin sont bien définies, même si le chemin n'est pas un caractère. chaîne. Toutefois, cette propriété ne s'applique pas nécessairement aux caractères restants du jeu de caractères du nom de fichier portable.

  • 3.272 composant de chemin d'accès

    Voir Nom de fichier dans Nom de fichier .

  • 3.170 Nom de fichier

    Une séquence d'octets consistant en 1 à {NAME_MAX}octets utilisés pour nommer un fichier. Les octets composant le nom ne doivent pas contenir les caractères <NUL>ou <slash>. Dans le contexte d'un chemin d'accès, chaque nom de fichier doit être suivi d'un <slash>ou d'un <NUL>caractère; ailleurs, un nom de fichier suivi d'un <NUL>caractère forme une chaîne (mais pas nécessairement une chaîne de caractères). Les noms de fichiers parsèment et dot-dotont une signification particulière. Un nom de fichier est parfois appelé "composant de chemin". Voir aussi Pathname .

Alors ... si vous voulez des éclaircissements , ce n'est peut-être pas votre premier arrêt. Des tutoriels tels que cette page des concepts UNIX sont utiles, par exemple, en soulignant que "chemin complet" est synonyme de "chemin absolu".

Thomas Dickey
la source
3
Nitpick: dot et dot-dot sont des noms de fichiers et non des noms de chemins. En fait, le standard POSIX a la curieuse formulation "Dans un cas particulier, dans le répertoire racine, point-point peut faire référence au répertoire racine lui-même". (mon emphase).
Kusalananda
Ainsi, la lecture de la spécification à la lettre /ne constitue pas un nom de fichier valide ni un composant de chemin d'accès, et ce n'est pas une chaîne contenant de tels composants, mais il s'agit toujours d'un chemin d'accès totalement valide pour un répertoire donné. Ce qui doit exister, bien que la partie qui l'exige ne mentionne pas son "nom". D'une certaine manière, je trouve cela légèrement amusant.
Ilkkachu
Il y a une réponse dans POSIX : il comporte des caractères de début facultatifs, suivis de zéro ou de plusieurs noms de fichiers séparés par des caractères.
Thomas Dickey
@Kusalananda examine la justification des spécifications de votre accent. la spécification may in spec est une déclaration de sécurité claire en ce qui concerne les tests de mise en œuvre. là où peut être utilisé, les spécifications garantissent à tout adhérent en herbe un comportement défini. en d' autres termes, toute mise en œuvre peut compter sur ..à /relier /.
mikeserv
19

Sous Unix, les fichiers (et les répertoires ne sont que des fichiers) n'ont pas de "noms". Les liens ont des noms, les liens sont des entrées dans un répertoire qui mappent les noms aux fichiers.

Vous pouvez dire que les liens donnent des noms aux fichiers, mais remarque: cela implique qu’un fichier peut avoir plus d’un nom, puisqu’il peut avoir plus d’un lien.

Etant donné que le répertoire racine est, eh bien, le répertoire racine, il n’existe pas de répertoire "plus haut" dans lequel il puisse y avoir un lien, donc il ne peut y avoir de nom associé. Il serait théoriquement possible d'ajouter un lien vers le répertoire racine dans un autre répertoire, mais la plupart des Unices interdisent l'ajout de liens vers des répertoires existants, car cela peut entraîner des cycles dans la hiérarchie du système de fichiers (qui est en réalité un graphe dirigé), ainsi que des cycles de détection. dans un graphique est coûteux, mais ne pas les détecter peut conduire à une récursion infinie lorsque vous essayez de résoudre des noms dans le noyau.

Donc, fondamentalement, le répertoire racine n’a pas de nom, car il n’y a pas de répertoire au-dessus dans lequel nous pourrions enregistrer le nom.

Comme cela a été souligné dans d'autres réponses, nous devons distinguer entre un nom et un chemin (nom). Le répertoire racine peut être référencé via le chemin (nom) /.

Jörg W Mittag
la source
Oui, les fichiers peuvent avoir plusieurs noms, tout comme les personnes. Le mari de ma plus jeune fille porte normalement son deuxième prénom, mais il doit également répondre à son prénom. Le nom principal du répertoire racine est "/", prononcé "slash", car son chemin absolu est "/" (et les noms basés sur des noms de chemins relatifs ne sont pas particulièrement utiles). (L'appeler "racine" risque de créer une confusion avec "/ racine", qui devrait toujours s'appeler "racine slash".
Monty Harder
1
J'aime le fait qu'il n'a pas de nom car il n'y a pas de répertoire plus élevé dans lequel enregistrer ce nom. Cela clarifie bien le concept.
Joe
7

L'utilisation du mot "nom" est un peu flexible; il peut faire référence à un "chemin d'accès complet"; il pourrait faire référence à "l'entrée de répertoire"; il pourrait faire référence au "nom de fichier" transmis à diverses fonctions ou routines.

Ainsi, par exemple, /etc/fooet /var/tmp/../../etc/fooet /tmp/../../../../../../foosont toutes les manières de se référer au même fichier; ce sont tous des noms valides , comme fooquand ils sont dans l' /etcannuaire.

Revenons donc à l'essentiel.

Un nom de fichier dans unix est constitué de composants séparés par le séparateur de répertoires /. La seule restriction relative aux composants est qu'ils ne peuvent pas contenir les /caractères ou NUL; tout le reste est autorisé.

Ainsi , le « nom de chemin complet » de /etcest la chaîne complète: /etc. Cela signifie que le etccomposant se trouve dans le répertoire racine.

De même /x/y/z/fooaurait le foocomposant dans le /x/y/zrépertoire.

À présent, le répertoire racine est unique en ce sens qu’il ne contient aucun composant dans un répertoire parent; il ne possède le chemin complet comme son nom: /.

Stephen Harris
la source