Résumé

  • Dans 9P2000, Twalk n’associe le newfid libre au résultat que si tous les éléments du nom ont été parcourus. Un Rwalk partiel peut rendre les qid d’un préfixe sans modifier aucun des deux fid.
  • Topen constitue une requête séparée : elle demande un mode d’accès, fait vérifier les permissions et prépare le fid aux futures lectures ou écritures. Ropen ne prouve aucun transfert de données.
  • L’histoire n’est pas celle d’un inventeur solitaire : Ken Thompson a commencé le protocole, Rob Pike y a intégré le système de noms, Dave Presotto a construit le réseau, et les articles comme les dialectes ultérieurs gardent leurs propres signatures.

Un navigateur de fichiers affiche « résolution réussie », puis l’ouverture échoue. Pour l’utilisateur, les deux états semblent incompatibles. Pour 9P, ils répondent simplement à deux questions différentes, posées à deux instants différents.

Twalk part d’un fid valide, propose un newfid et transmet une liste d’éléments de nom. Sauf si le client choisit expressément le même numéro que le fid de départ, newfid doit être libre. Le serveur avance élément par élément et exige la permission de recherche dans chaque répertoire traversé. Lorsque toute la liste aboutit, Rwalk renvoie autant de qid que d’éléments et newfid représente le résultat.

Ce reçu est précis : sur ce serveur, dans cette connexion, depuis ce fid et dans cet ordre, la résolution a réussi. Il ne contient pas une ouverture implicite. L’introduction du protocole décrit les fid comme des identifiants 32 bits choisis par le client pour ses fichiers courants, ouverts ou non. Leur espace est partagé dans la connexion. Une nouvelle négociation de version réinitialise la session et abandonne les opérations en cours. Le fid est donc un instrument de contexte, pas une identité durable au-delà de la session.

Les réponses incomplètes empêchent une autre généralisation. Un échec sur le premier nom donne une erreur. Si l’échec arrive plus loin, Rwalk peut restituer les qid du préfixe parcouru. Pourtant, dans 9P2000, ni l’ancien fid ni le newfid ne change tant que tous les éléments n’ont pas réussi. Un outil qui convertit « cinq éléments sur sept » en nouveau handle utilisable fabrique un état absent du protocole.

Le cas sans élément est tout aussi instructif : Twalk clone alors le fid dans newfid, sans parcourir de nom. Quant à MAXWELEM, il limite à seize le nombre d’éléments dans un message, pas la profondeur logique du chemin ; plusieurs walks peuvent se suivre. Une trace doit donc distinguer parcours, clonage et segmentation des messages.

Topen intervient ensuite. Elle demande que le fichier déjà représenté par le fid soit ouvert en lecture, écriture, lecture-écriture ou exécution, avec les options prévues par 9P2000. Le serveur vérifie les droits et prépare le fid aux E/S. Ropen rend un qid et une unité d’E/S. La lecture ou l’écriture ne sera attestée que par une opération ultérieure.

Le temps sépare encore les preuves. Le manuel d’open indique que les permissions sont contrôlées au moment de l’ouverture et qu’une modification ultérieure ne retire pas l’accès d’un fichier déjà ouvert. Les droits de recherche utilisés pendant walk ne garantissent donc pas le mode demandé par open. Un refus après un walk complet peut être parfaitement cohérent : l’autorisation demandée, l’état du fichier ou le serveur ont changé. À l’inverse, un fid déjà ouvert peut continuer d’accéder au fichier après une nouvelle politique. Sans horodatage et ordre des échanges, le journal raconte une autre histoire.

Le qid a lui aussi une portée. Il identifie un fichier dans une même hiérarchie de serveur et sa partie path doit changer si le fichier est supprimé puis recréé. Il apporte davantage qu’un simple nom affiché. Il n’est toutefois ni une identité mondiale entre serveurs, ni une empreinte du contenu, ni la preuve que deux points de montage désignent le même objet.

Cette localité exprime le projet de Plan 9. Dans The Use of Name Spaces in Plan 9, Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey et Phil Winterbottom décrivent des espaces de noms par processus, assemblés au moyen d’un protocole de fichiers réduit. Plan 9 from Bell Labs, signé par Pike, Presotto, Sean Dorward, Bob Flandrena, Thompson, Trickey et Winterbottom, souligne que la composition du nom reste côté client. L’absence d’arbre universel est une liberté d’assemblage, pas un défaut de résolution.

L’attribution doit être aussi locale que le reçu. La préface de la deuxième édition explique que Thompson a commencé le protocole, que Pike a intégré les noms et que Presotto a bâti le réseau, tout en créditant Winterbottom et beaucoup d’autres. Dire seulement « le protocole de Pike » efface précisément le travail collectif qui rend son rôle d’intégration intelligible.

Les versions suivantes imposent la même prudence. La préface de la quatrième édition relie le nouveau 9P principalement à la suppression de l’ancienne limite de 27 octets par élément de nom, ainsi qu’à des gains d’efficacité, de souplesse et d’encapsulation. Linux v9fs sait négocier 9p2000, 9p2000.u et 9p2000.L. L’extension UNIX et le dialecte Linux ont leurs propres textes ; 9P2000.L conserve la structure de walk mais utilise notamment Tlopen et Rlopen avec des indicateurs Linux. La frontière en deux temps demeure, pas l’identité de tous les champs.

Enfin, le cache peut créer une distance entre observation du client et état vivant du serveur. Les modes de cache de v9fs appartiennent donc au dossier de preuve. Il faut conserver dialecte, connexion, serveur et export, contexte d’attach, fid et qid de départ, noms ordonnés, qid rendus, caractère complet ou partiel, newfid, mode d’open, qid et iounit de Ropen, E/S suivantes, politique de cache et fin de session.

Ainsi, « walk a réussi » reste une conclusion forte. Elle dit que les noms ont été résolus là où le protocole le garantit. Rien n’avait besoin d’être ouvert pour que cette phrase soit vraie.

Sources