Summary

  • RFC 775 décrit quatre commandes FTP expérimentales conçues chez BBN pour créer, supprimer et parcourir des répertoires pendant la maintenance de sites distants.
  • La création devait renvoyer le chemin absolu reconnu par le serveur. Sur TOPS-20, le nom bref fourni à XMKD pouvait être inutilisable pour la commande suivante.

Le répertoire existe. Le client l'a demandé. Et pourtant, impossible d'y entrer. Le cas n'a rien d'une parabole sur l'administration informatique : RFC 775 en donne les commandes. Sur un serveur TOPS-20, XMKD MYDIR peut réussir, tandis que XCWD MYDIR échoue. La machine n'a pas perdu le dossier. Elle l'a rangé sous un nom que la commande de création ne livrait pas à elle seule.

À l'origine, BBN entretenait plusieurs DEC PDP-11 sous UNIX pour un projet de maintenance de sites distants de l'ARPA. Une arborescence se copie mal si FTP sait déplacer les fichiers mais ne peut pas construire les répertoires qui les contiennent. Les ingénieurs ont donc ajouté XMKD pour créer un répertoire, XRMD pour le supprimer, XPWD pour demander où l'on se trouve et XCUP pour remonter au parent. Ce dernier geste évitait au programme de deviner comment chaque système écrit « le dossier au-dessus ».

Le souci se révélait au moment de passer d'un système à l'autre. UNIX, TOPS-20 et Multics pouvaient tous organiser des répertoires en arbre. Ils n'écrivaient pas pour autant les chemins de la même façon. Supposons que le client se trouve dans <DFRANKLIN> et demande XMKD MYDIR. Le nouveau répertoire peut porter le nom complet <DFRANKLIN.MYDIR>. Appeler ensuite XCWD MYDIR ne suffit pas forcément. L'argument de création désigne une opération relative à un contexte; il ne constitue pas nécessairement l'adresse durable de son résultat.

La solution de RFC 775 tient dans la réponse. Après une création réussie, le serveur doit renvoyer une ligne 257 contenant le nom absolu entre guillemets. L'exemple UNIX est 257 "/usr/dm/child" directory created. Pour TOPS-20, la réponse prend sa syntaxe à lui. Même le guillemet présent dans un nom reçoit un traitement précis : on le double dans la chaîne retournée. Ainsi, un programme peut lire la réponse sans casser le chemin au milieu. Le protocole cesse de demander au client de jouer au devin avec les conventions du voisin.

L'arborescence explique cette minutie. Pour reproduire une branche sur la machine d'arrivée, le programme doit savoir où il est, créer un enfant, conserver le nom retourné, entrer dans cet enfant, copier son contenu, puis remonter. S'il transforme par habitude MYDIR en chemin UNIX, il peut avoir bien créé le répertoire tout en perdant l'accès à sa destination. Le paquet arrive; la structure, elle, peut se retrouver à la mauvaise adresse.

Le texte prévoit aussi le cas d'un répertoire qui porte déjà ce nom. BBN y répond par une erreur 521 et ne crée rien de plus. Il donne parallèlement des codes pour l'ancien FTP alors utilisé et des équivalents envisagés pour le protocole plus récent de RFC 765. Le 257 appartient à la première série; 251 est le code proposé dans la seconde. Une spécification en cours d'évolution laisse parfois deux colonnes de chiffres derrière elle.

RFC 765 promettait déjà d'atténuer les différences entre systèmes de fichiers, tout en reconnaissant l'absence de convention universelle pour les chemins. RFC 775 a choisi un accord plus modeste et plus efficace : la machine qui crée le répertoire dit comment le retrouver. Dans RFC 959, publié cinq ans plus tard, MKD, RMD, PWD et CDUP figurent parmi les nouvelles commandes facultatives. Le X expérimental a disparu; la difficulté de nommer le bon dossier a laissé une trace dans le protocole.