Résumé

  • La RFC 959 autorisait, de façon optionnelle, le montage d’une autre structure de fichiers sans modifier la connexion, la comptabilité ni les paramètres de transfert.
  • Un chemin identique pouvait donc désigner deux ressources différentes selon l’état de montage ; conserver la chaîne de caractères ne suffisait pas à conserver l’objet.
  • Le contraste avec HOST, qui doit précéder l’authentification lorsque l’hôte virtuel détermine les utilisateurs admis, montre quelles dépendances imposent de rouvrir l’identité.

Un changement silencieux au milieu de la session

Une connexion de contrôle est ouverte. L’utilisateur s’est identifié, le serveur a accepté les éventuelles informations de compte, et les deux parties ont choisi un type de représentation et un mode de transfert. Le client connaît un chemin. Puis il envoie SMNT avec le nom d’une autre structure.

La RFC 959 décrit précisément ce qui doit rester en place : les informations de connexion et de comptabilité, ainsi que les paramètres de transfert. Le contrôle TCP ne repart pas de zéro. L’utilisateur ne présente pas à nouveau ses justificatifs. Pourtant, la prochaine résolution d’un chemin se déroule sur un autre socle.

La brièveté du texte est trompeuse. Il ne s’agit pas seulement d’un ancêtre de bouton « changer de volume ». La norme dissocie quatre états que l’interface pourrait confondre : qui agit, sous quel compte, avec quels réglages de transfert, et dans quelle structure les noms prennent sens.

Trois verbes pour trois profondeurs de changement

La même RFC donne deux repères. CWD déplace le répertoire de travail sans modifier l’identité ni le compte. Le mouvement reste intérieur à la structure courante. REIN, au contraire, vide l’utilisateur, le compte et les paramètres de transfert afin de ramener la connexion vers l’état d’une nouvelle ouverture.

SMNT occupe l’espace entre les deux. Il ne se contente pas de déplacer le point courant, mais il ne détruit pas non plus toute la session. Il change le système qui interprète les emplacements tout en gardant le principal et plusieurs réglages opérationnels.

Cette distinction empêche une erreur de lecture historique. CWD, SMNT et REIN ne sont pas trois variantes de navigation. Le premier change la position, le deuxième change la structure de résolution, le troisième réinitialise le contexte de session. Chacun invalide un ensemble différent d’hypothèses.

La chaîne exacte ne garantit pas la même ressource

FTP n’a jamais imposé une syntaxe universelle des chemins. La RFC 959 renvoie aux conventions des systèmes de fichiers concernés. La RFC 3659, lorsqu’elle ajoute des mécanismes plus précis, recommande encore de conserver et de retransmettre exactement les chemins fournis par le serveur, car leur syntaxe reste dépendante de celui-ci en dehors du modèle TVFS.

Cette discipline protège les octets ; elle ne fige pas le contexte. Après un SMNT réussi, /archives/rapport peut présenter exactement les mêmes caractères et conduire ailleurs. Le changement peut modifier la racine, le support, la politique ou tout simplement l’ensemble de fichiers visible.

Un relevé probant doit donc joindre au chemin l’extrémité serveur, le principal authentifié, l’hôte virtuel sélectionné le cas échéant, la structure montée, le répertoire courant et l’instant. Un journal qui ne conserve que l’utilisateur et le chemin ressemble à une preuve complète, alors qu’il manque la variable qui a décidé de l’objet.

La norme ne permet pas d’affirmer que toutes les mises en œuvre de SMNT offraient le même modèle de montage. Le groupe de fichiers est explicitement dépendant du système. La conclusion solide est plus limitée : le protocole a normalisé le changement de ce contexte sans imposer la perte des autres états.

Une opération de contrôle d’accès

La RFC 5797, qui formalise le registre des commandes FTP, classe SMNT parmi les commandes de contrôle d’accès. Elle la marque comme optionnelle et la rattache au socle historique. Ce classement est plus instructif que l’image d’une simple arborescence interchangeable.

Si la structure active change, l’ensemble des objets atteignables et le résultat d’une résolution peuvent changer. L’autorisation doit être évaluée dans ce nouvel état. Le succès antérieur de l’authentification n’est pas une permission générale de monter n’importe quelle structure, et l’existence du verbe dans un registre n’est pas la preuve qu’un serveur l’accepte.

La RFC 1123 dessine la ligne d’interopérabilité : CWD est obligatoire, SMNT reste optionnel. Tout serveur conforme devait savoir déplacer un utilisateur dans son espace courant ; il n’était pas tenu d’autoriser le remplacement de cet espace.

Le registre IANA conserve le nom, sa classe et sa référence. Il prouve la coordination du vocabulaire, pas un déploiement contemporain, une permission donnée ni un montage accompli. Une réponse positive dans une trace de session ajouterait la preuve d’une transition acceptée, sans encore établir que les chemins identiques entourant cette transition visaient le même objet.

Quand l’hôte doit venir avant l’identité

Une extension plus récente adopte l’ordre inverse. La RFC 7151 définit HOST pour choisir un hôte virtuel sur un serveur partagé. La commande doit arriver avant l’authentification ; après celle-ci, le serveur répond 503.

La raison touche précisément à la dépendance de l’identité. L’hôte sélectionné peut déterminer les méthodes d’authentification disponibles et la liste des utilisateurs autorisés. Changer d’hôte reviendrait alors à changer le domaine dans lequel le principal a été reconnu. L’ancienne authentification ne peut pas être transportée sans examen.

HOST n’a pas remplacé SMNT, et leurs fonctions ne sont pas équivalentes. Leur contraste fournit néanmoins un test utile. Si le contexte ne change que l’espace de ressources sous une identité autonome, la session peut éventuellement survivre, avec une nouvelle décision d’autorisation. Si le contexte définit les identités admissibles elles-mêmes, il doit être choisi avant l’authentification.

Ce que ce vestige garde vivant

SMNT paraît exotique parce que peu d’utilisateurs montent aujourd’hui des structures depuis une session FTP. Le problème qu’il expose est partout. Une console conserve la même personne tout en changeant d’organisation ; des identifiants cloud restent chargés pendant qu’un projet actif bascule ; un conteneur change de vue sur les montages sans changer de processus.

Ces systèmes ne sont pas des copies de FTP. Le parallèle pertinent tient à la méthode : indiquer quel état persiste, quel état change et quelles autorisations doivent être recalculées.

Une identité n’est pas un espace de noms. Un chemin n’est pas une ressource hors de son contexte de résolution. Une session continue ne prouve pas la continuité du plan de stockage. SMNT a inscrit ces différences dans une commande minuscule. La connexion survécut ; c’est pourquoi le montage devait laisser une trace.

Sources