Résumé

  • RNFR et sa réponse 350 plaçaient le chemin source dans un état positif mais inachevé ; aucun nouveau nom n’était encore confirmé.
  • Le RNTO immédiatement suivant fournissait la destination, et son résultat final séparait l’intention, l’autorisation et l’exécution.
  • Les faits MLSx ont ensuite distingué droit sur la source, capacité de création dans la destination et indice optionnel de continuité de l’objet, sans promettre atomicité ni durabilité.

Le piège du chiffre positif

Le client envoie RNFR avec un ancien chemin. Le serveur répond 350, action de fichier en attente d’informations supplémentaires. Comme le premier chiffre est positif, un tableau de bord sommaire pourrait afficher « succès ».

La RFC 959 dit pourtant exactement l’inverse d’un achèvement. Une réponse 3xx est positive intermédiaire : la commande est acceptée, mais l’action reste suspendue jusqu’à la réception d’une autre information. Pour le renommage, cette information est le chemin fourni par RNTO.

La RFC 765 possédait déjà ce couple. RNFR désigne le fichier et doit être immédiatement suivi par RNTO. La seconde commande désigne le nouveau chemin du fichier cité par la commande précédente. C’est leur ensemble qui provoque le renommage.

Ce que le serveur gardait en mémoire

FTP classe le couple parmi les groupes séquentiels. Les réponses signalent qu’une étape antérieure a atteint un état intermédiaire valable. Si une étape échoue, la séquence entière doit être recommencée depuis le début.

Le serveur conserve donc un contexte de source dans la connexion de contrôle. La norme ne crée pas pour autant un identifiant transactionnel portable, un verrou, une réservation du nom cible ou une garantie de stabilité du fichier.

Le mot « immédiatement » lie les deux commandes. Un RNTO sans RNFR précédent peut produire 503, mauvaise séquence. Pour reconstituer l’opération, un journal doit conserver la même session, l’ordre exact, les deux chemins et les deux réponses. Deux lignes isolées portant les bons verbes ne suffisent pas.

350 invite à continuer ; 250 clôt l’action

Dans le modèle des réponses, 2xx signifie achèvement positif. 250 déclare l’action demandée correcte et terminée. 350, lui, demande une information supplémentaire.

Cette différence est un état, pas une préférence d’interface. Après 350, le client possède la permission protocolaire de poursuivre. Après un 250 associé à RNTO, il possède la preuve protocolaire que le serveur a achevé la demande.

Si la réponse finale disparaît avec la connexion, le résultat devient inconnu. Un client prudent relit l’espace de noms avant toute répétition. Le 350 mémorisé n’est pas un jeton durable permettant de reprendre au milieu ; la règle d’échec du protocole renvoie au commencement de la séquence.

Deux surfaces de permission

La RFC 3659 rend visible la séparation des autorités grâce au fait perm. La lettre f appliquée à un objet indique qu’il peut être la cible de RNFR. La lettre c appliquée à un répertoire indique que des fichiers peuvent y être créés et que RNTO a des chances d’y réussir.

La source et le contenant de destination portent donc des capacités différentes. Et le texte dit « a des chances », pas « réussira ». Un relevé MLSx décrit la situation du présent utilisateur au moment de l’observation ; il ne réserve pas le nom, ne gèle pas les règles et ne remplace pas la réponse finale.

Un droit de libérer ou renommer un objet ne doit pas être transformé en droit de créer un nom partout. Le vieux couple rappelle pourquoi les produits modernes devraient éviter un bouton unique « peut modifier » lorsque l’action traverse deux domaines de contrôle.

Un indice d’objet au-delà du nom

RFC 3659 définit aussi le fait optionnel Unique. Deux chemins visant le même fichier sous-jacent devraient avoir le même jeton opaque ; deux fichiers distincts, des jetons différents. La correspondance doit rester cohérente au moins pendant la connexion de contrôle.

Dans un exemple, mlst.c possède un jeton. Le serveur répond 350 à RNFR, puis 250 à RNTO list.c. La liste suivante montre list.c avec le même jeton. Le nom a changé tandis que l’indice borné de l’objet reste stable.

Cette scène n’est pas une garantie universelle. Aucun fait précis n’est obligatoire sur tous les serveurs ; le jeton n’est ni mondial, ni permanent, ni dérivé du contenu. Il montre seulement comment une preuve distincte peut relier l’objet avant et après le changement de nom.

Le résultat de renommage et l’indice d’identité ont des fonctions différentes. L’un atteste l’action acceptée et terminée ; l’autre peut renforcer l’idée que les deux noms successifs désignent un même objet sous-jacent.

Le registre ne décrit pas la transaction du disque

La RFC 1123 conserve les deux commandes dans les exigences FTP. La RFC 5797 les range parmi les commandes obligatoires de base. Le registre IANA préserve leurs entrées.

Ces sources coordonnent un langage. Elles ne promettent pas un renommage atomique pour les lecteurs concurrents, une politique d’écrasement, un passage entre systèmes de fichiers, une écriture durable ou une reprise après panne. Elles ne prouvent pas non plus le déploiement ou l’autorisation sur un serveur précis.

Leur apport est plus sobre et plus solide : elles obligent à ne pas confondre la sélection d’une source en attente avec l’achèvement d’une mutation.

Une grammaire pour les actions à plusieurs étapes

Le protocole a donné un nom observable à l’entre-deux. C’est ce que beaucoup de systèmes de contrôle contemporains perdent lorsqu’ils ramènent « proposition reçue », « validation réussie », « travail planifié » et « changement commis » à une coche verte.

Un bon service décrit ce qu’il retient, pendant combien de temps, ce qui annule l’état et quelle réponse prouve l’achèvement. Il sépare aussi le pouvoir sur la source, le pouvoir sur la destination et la preuve de continuité de l’objet.

Le 350 de FTP n’était pas un mauvais succès. C’était un succès non final précis. Le renommage n’avait pas encore eu lieu, et le protocole l’avouait.

Sources