La barre oblique (/) fait-elle partie du nom du répertoire racine Linux?
La barre oblique (/) fait vraiment partie du nom du répertoire racine Linux? Ou est-ce juste un symbole pour cela?
Qu'en est-il de /etc etc?
Mise à jour
Supposons que /dev/sda2 est 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: /[.____. diplomatiqueroot] INODE: 2 PATH: / debugfs: stat /[.____. depositedInode: 2 Type: répertoire Mode: 0755 Indicateurs: 0x80000 Génération: 0 Version: 0x00000000: 00000077 Utilisateur: 0 Groupe: 0 Projet: 0 Taille: 4096 ACL du fichier: 0 Liens: 25 Blockcount: 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 17 mars 16:59:39 2018 Taille des champs d'inode supplémentaires: 32 EXTENTS: (0): 9249
Il y a donc un répertoire là-dedans, inode # 2, mais il n'a pas de nom.
La norme POSIX.1-2008 dit
Un chemin d'accès composé d'un seul
/doit se résoudre dans le répertoire racine du processus. Un chemin d'accès nul ne doit pas être résolu avec succès.
La norme fait en outre une distinction entre noms de fichiers et noms de chemins. / est le chemin d'accès du chemin du répertoire racine. Le nom du répertoire est "le répertoire racine", mais dans le système de fichiers, il est sans 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 au-dessus du répertoire racine, et il n'y a pas un tel répertoire.
Le personnage / ne peut jamais faire partie d'un nom de fichier car il s'agit du séparateur de chemin.
Pour plus de clarté: / n'est pas le nom du répertoire racine, mais le chemin vers celui-ci, son nom de chemin.
/etc est un autre nom de chemin. Il s'agit du nom du chemin absolu du répertoire etc. Le nom du répertoire sur ce chemin est etc (son nom de fichier est etc).
/usr/local/bin/curl est le chemin d'accès du fichier exécutable curl de la même manière que /etc est le chemin d'accès du répertoire etc.
la barre oblique est un séparateur; répertoire noms n'inclut pas les séparateurs, mais noms de chemin complets inclut les séparateurs.
Ainsi, le "niveau racine"/ N'a pas de nom . Sur la plupart des systèmes de type Unix, cela est traité comme un cas spécial comme . Et .. (Bien qu'il n'y ait bien sûr aucune différence entre les deux au niveau racine).
La nomenclature peut différer. POSIX.1-2017, par exemple, répertorie quelques-uns couramment utilisés définitions :
Un chemin commençant par un ou plusieurs caractères
<slash>; voir aussi Pathname .Chaîne utilisée pour identifier un fichier. Dans le contexte de POSIX.1-2008, un chemin d'accès peut être limité à {PATH_MAX} octets, y compris l'octet nul final. Il comporte des caractères de début facultatifs
<slash>, Suivis de zéro ou plusieurs noms de fichiers séparés par des caractères<slash>. Un chemin d'accès peut éventuellement contenir un ou plusieurs caractères de fin<slash>. Plusieurs caractères<slash>Successifs sont considérés comme étant identiques à un<slash>, À l'exception du cas d'exactement deux caractères<slash>En tête.
Remarque: Si un nom de chemin se compose uniquement d'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 ),<slash>Caractères et une seule terminaison<NUL>Caractère, le chemin d'accès sera utilisable comme chaîne de caractères dans tous les paramètres régionaux pris en charge; sinon, le chemin d'accès pourrait être uniquement une chaîne (plutôt qu'une chaîne de caractères). De plus, étant donné que l'encodage à un octet du caractère<slash>Doit être le même dans tous les paramètres régionaux et ne pas se produire dans un caractère à plusieurs octets, les références à un caractère<slash>Dans un chemin d'accès sont bien définis même lorsque le chemin d'accès n'est pas une chaîne de caractères. Cependant, cette propriété ne s'applique pas nécessairement aux caractères restants dans le jeu de caractères de nom de fichier portable..272 Composant de chemin d'accès
Voir Nom de fichier dans Nom de fichier .
Une séquence d'octets composée de 1 à
{NAME_MAX}Octets utilisée pour nommer un fichier. Les octets composant le nom ne doivent pas contenir les caractères<NUL>Ou<slash>. Dans le contexte d'un nom de chemin, chaque nom de fichier doit être suivi d'un caractère<slash>Ou<NUL>; ailleurs, un nom de fichier suivi d'un caractère<NUL>forme une chaîne (mais pas nécessairement une chaîne de caractères). Les noms de fichiers point etdot-dotont une signification particulière. Un nom de fichier est parfois appelé "composant de chemin d'accès". Voir aussi Pathname .
Donc ... si vous cherchez clarification, ce n'est peut-être pas votre premier arrêt. Des didacticiels tels que cette page Concepts UNIX sont utiles, par exemple, en soulignant que "chemin d'accès complet" est synonyme de "chemin d'accès absolu".
Sous Unix, les fichiers (et les répertoires ne sont que des fichiers) n'ont pas de "noms". Liens ont des noms, les liens sont des entrées dans un répertoire qui mappent les noms aux fichiers.
Vous pourriez dire que les liens donner des noms aux fichiers, mais notez: cela implique qu'un fichier peut avoir plus d'un nom, car il peut avoir plus d'un lien.
Puisque le répertoire racine est, eh bien, le répertoire racine, il n'y a pas de répertoire "supérieur" dans lequel il pourrait y avoir un lien, donc il ne peut pas 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 d'ajouter des liens vers des répertoires existants, car cela peut conduire à des cycles dans la hiérarchie du système de fichiers (qui est en fait un graphique dirigé) et à détecter des cycles dans un graphe coûte cher, 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 de lui dans lequel nous pourrions enregistrer le nom.
Comme cela a été souligné dans d'autres réponses, nous devons faire la distinction entre un nom et un chemin (nom). Le répertoire racine peut être référencé via le chemin (nom) /.
L'utilisation du mot "nom" est un peu flexible; il peut faire référence à un "nom de 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/foo et /var/tmp/../../etc/foo et /tmp/../../../../../../foo sont tous des moyens de faire référence au même fichier; ils sont tous valides noms, tout comme foo lorsqu'ils sont dans le /etc répertoire.
Revenons donc à l'essentiel.
Un nom de fichier sous Unix est composé de composants séparés par le séparateur de répertoire /. À peu près la seule restriction sur les composants est qu'ils ne peuvent pas contenir le / ou caractères NUL; tout le reste est autorisé.
Ainsi, le "nom de chemin d'accès complet" de /etc est la chaîne complète: /etc. Cela signifie qu'il a le composant etc dans le répertoire racine.
De même /x/y/z/foo aurait le composant foo dans le /x/y/z répertoire.
Maintenant, le répertoire racine est unique en ce qu'il n'a aucun composant dans un répertoire parent; it seulement a le nom de chemin complet comme nom: /.