Pourquoi '/' contient '..'?
Il n'y a pas de répertoire au-dessus de /, alors à quoi sert le .. dedans?
Le .. l'entrée dans le répertoire racine est un cas particulier.
Du standard POSIX ( 4.13 Pathname Resolution , où le . et .. les entrées sont appelées respectivement "point" et "point-point"):
Le point de nom de fichier spécial fait référence au répertoire spécifié par son prédécesseur. Le nom de fichier spécial point-point doit faire référence au répertoire parent de son répertoire prédécesseur. Dans un cas particulier, dans le répertoire racine, point-point peut faire référence au répertoire racine lui-même.
La justification a ceci à ajouter ( A.4.13 Résolution de chemin d'accès )
Ce à quoi le nom de fichier point-point fait référence par rapport au répertoire racine est défini par l'implémentation. Dans la version 7, il fait référence au répertoire racine lui-même; c'est le comportement mentionné dans POSIX.1-2017. Dans certains systèmes en réseau, la construction
/../hostname/est utilisé pour faire référence au répertoire racine d'un autre hôte, et POSIX.1 autorise ce comportement.D'autres systèmes en réseau utilisent la construction
//hostnamedans le même but; c'est-à-dire une double initiale<slash>est utilisé. [...]
Donc, en bref, la norme POSIX dit que chaque répertoire doit avoir à la fois . et .. entrées et autorise la .. entrée de répertoire dans / pour faire référence à / répertoire lui-même (notez le mot "peut" dans le premier texte cité), mais il permet également à une implémentation de la renvoyer à autre chose.
Les implémentations les plus courantes des systèmes de fichiers font /.. décidez de /.
Kusalananda vous a déjà dit que c'est le comportement spécifié par la norme POSIX. Cependant, l'histoire d'UNIX a commencé sérieusement au début des années 1970. POSIX ne remonte qu'à la seconde moitié des années 80, une décennie et demie plus tard. En pratique, POSIX a simplement spécifié ce qui était déjà fait par les implémentations.
Au contraire, UNIX a très tôt pris en charge le montage de systèmes de fichiers sur différents périphériques dans sa hiérarchie de répertoires unifiés. Chaque système de fichiers a en effet son propre répertoire racine ; le système de fichiers monté sur / n'est pas particulièrement spécial en aucune façon. (Son contenu pourrait l'être, mais le système de fichiers lui-même ne l'est pas.)
Les appels système sysmount et sysumount semblent avoir été introduits dans UNIX V1, en 1970-1971 (V1 est daté de 1971-11, selon l'arborescence Unix de The Unix Heritage Société ). Ils sont définis dans 1.s (numéros d'appel système 21 et 22, respectivement) et implémentés dans 7.s . (PDP7 UNIX, daté du 1970-01, ne semble pas avoir d'ancêtre évident de ceux-ci ).
Vous voyez probablement où cela va: quand any le système de fichiers peut être monté à any emplacement dans la hiérarchie, pour éviter d'avoir à faire des choses spéciales, chaque répertoire, y compris le répertoire racine de chaque système de fichiers, doit contenir une entrée pointant vers son propre répertoire parent. Sur le disque, l'endroit logique où pointer l'entrée du répertoire parent du système racine d'un système de fichiers est le répertoire racine du système de fichiers, car il n'y a rien d'autre "au-dessus" du répertoire racine du système de fichiers. Le concept d'avoir quelque chose "au-dessus" du répertoire racine n'entre en jeu que lorsque ce système de fichiers est monté à un emplacement autre que la racine de la hiérarchie.
Pendant le montage, il est possible de réécrire le pointeur "répertoire parent" dans la copie mémoire du répertoire racine pour pointer vers le répertoire parent du répertoire du point de montage. S'il n'y a pas de répertoire parent du répertoire de point de montage (en d'autres termes, le système de fichiers est monté en tant que /), puis laissez ce morceau de données seul (car il n'y a probablement nulle part d'autre sens pour le pointer de toute façon) ou manipulez-le séparément plus tard (comme ce serait probablement le cas pour le /../hostname/path et //hostname/path cas mentionnés dans la réponse de Kusalananda).
Le comportement résultant est que dans tout répertoire autre que /, qu'il s'agisse du répertoire racine d'un système de fichiers particulier ou d'un sous-répertoire (à n'importe quel niveau d'imbrication), .. pointe vers le répertoire parent de ce répertoire; et en /, .. pointe vers /. Le premier est ce qui semble naturel (.. fonctionne toujours de la même manière, vous faisant avancer d'un pas vers le répertoire racine), tandis que ce dernier, bien que légèrement idiosyncrasique, au moins ne casse évidemment rien (il y a peu dommage en pas pouvoir aller plus loin vers le répertoire racine que vers le répertoire racine lui-même). Par exemple, vous pouvez définir un nombre arbitraire de ../ et sachez que ces au moins ne causeront pas d'erreur car .. à un moment donné n'existe pas.
Il y a un répertoire au-dessus de /, / Lui-même. Le répertoire parent du répertoire racine est lui-même. cd .. Ou cd ../.. Dans le répertoire racine devrait vous laisser au même endroit, sans provoquer d'erreur.
Notez que ni . Ni .. Ne peuvent exister comme entrées de répertoire réelles dans certains systèmes de fichiers, ils peuvent être simplement émulés par la couche du système de fichiers virtuel du système d'exploitation.
Un chemin comme /../hostname Est censé vous avoir permis d'accéder à la racine d'un autre hôte dans certains systèmes pre-vfs et pre-nfs comme MUNIX = (en utilisant "Newcastle Connection" ) mais je ne connais aucun système de ce type encore utilisé, et le code source est introuvable.
Les informations disponibles sont très contradictoires, mais il semble que la façon la plus courante de déployer un tel système était de recompiler tous les programmes afin que tous les appels utilisant le chemin comme open(2) pouvait être redirigé dans l'espace utilisateur (il n'y avait pas de bibliothèques partagées à cette époque).
Il y avait probablement des centaines de tels hacks ( scratchbox étant un plus récent que j'ai eu le déplaisir d'avoir à utiliser), donc ce n'est pas du tout clair pourquoi ils ont ressenti le besoin de l'adapter dans le standard POSIX .
Au-delà de toutes les autres raisons mentionnées ici, c'est simplicité de conception, quelque chose pour lequel UNIX est connu. Tous les répertoires contiennent ..; les cas spéciaux sont toujours des risques de déclenchement (pour la sécurité ou la robustesse) qui se profilent dans le noir. Ainsi, au lieu de forcer les programmeurs à gérer un cas rare dans de nombreux endroits, tous les répertoires sont conçus pour avoir . et .. entrées et sont traitées de manière uniforme, et prise en compte de ce qui se passe à / n'est pas nécessaire.