Summary

  • En diciembre de 1980, RFC 775 describió cuatro órdenes experimentales de FTP para crear, borrar y recorrer directorios durante el mantenimiento remoto de equipos.
  • La respuesta a una creación debía incluir el nombre absoluto que entendía el servidor: en TOPS-20, la palabra usada para crear un directorio podía fallar al usarse para entrar en él.

La secuencia es casi una broma de terminal: XMKD MYDIR, éxito; XCWD MYDIR, fracaso. RFC 775 la expone para resolver un problema nada cómico: copiar un árbol de directorios entre equipos que no escriben las rutas de la misma manera. El directorio recién creado no había desaparecido. El cliente estaba llamándolo por el nombre equivocado.

BBN mantenía software en varios DEC PDP-11 con UNIX dentro de un proyecto de mantenimiento remoto de ARPA. Para copiar una estructura completa, mover archivos era solo una parte del trabajo. Había que crear las ramas que los alojarían y desplazarse por ellas. Los ingenieros ampliaron sus servidores FTP con cuatro verbos: XMKD crea, XRMD elimina, XPWD dice dónde está el proceso y XCUP sube al directorio padre. Este último evitaba memorizar cómo representa cada sistema el escalón superior.

El cruce entre sistemas era el verdadero campo de pruebas. UNIX, TOPS-20 y Multics podían organizar directorios en forma de árbol, pero sus reglas para nombrarlos diferían. En el ejemplo de RFC 775, el cliente está conectado a <DFRANKLIN> en TOPS-20 y solicita XMKD MYDIR. El servidor crea <DFRANKLIN.MYDIR>. Una orden posterior XCWD MYDIR puede fallar: MYDIR sirvió para pedir la creación de un hijo, pero no necesariamente para identificarlo después. Hay éxitos que entregan una dirección distinta de la que se escribió en el formulario.

Por eso la respuesta tenía que devolver el camino completo entre comillas. El RFC propone una línea 257 y muestra, para UNIX, 257 "/usr/dm/child" directory created. En TOPS-20, el nombre reflejaría la sintaxis propia del servidor. También fija cómo escribir comillas dentro del nombre: duplicándolas. Esa regla minúscula permite al programa analizar la respuesta aunque una carpeta se llame foo"bar. El servidor conoce el sistema de archivos que acaba de modificar; el cliente debe guardar el resultado que el servidor declara.

La operación completa se entiende al imaginar un árbol en movimiento. El programa crea un hijo en el destino, recibe su ruta absoluta, entra, carga los archivos, fabrica los nietos y después vuelve al padre. Si reconstruye la ruta con costumbres de UNIX, puede desorientarse aunque los bytes de los archivos viajen sin un solo error. En este episodio, el tráfico de red no era el obstáculo; era la dirección del inmueble.

RFC 775 también describe la puerta cerrada: si el directorio ya existe, la implementación de BBN devuelve un error 521 y no actúa. Sus tablas presentan los códigos que usaba el FTP antiguo y, entre paréntesis, equivalentes propuestos para la versión más nueva de RFC 765. El 257 recién añadido pertenece a la primera; 251 era la propuesta para la segunda. Mezclarlos borraría precisamente la transición que muestran las fuentes.

RFC 765 quería proteger al usuario de las diferencias entre sistemas de archivos, aunque admitía que FTP todavía no tenía una convención universal para las rutas. RFC 775 aceptó esa realidad y convirtió la respuesta del destino en una pieza fiable del diálogo. RFC 959, de 1985, ya enumeraba MKD, RMD, PWD y CDUP como órdenes opcionales nuevas, sin la X experimental. La lección sobrevivió al prefijo: crear algo en otra máquina exige saber cómo esa máquina lo llama.