Resumen

  • RNFR más 350 establecían un estado intermedio positivo: el servidor había aceptado la fuente, pero el nombre aún no había cambiado.
  • El RNTO inmediatamente posterior aportaba el destino; su respuesta final separaba continuación autorizada de mutación completada.
  • Los hechos MLSx posteriores distinguieron capacidad sobre la fuente, creación en el destino y evidencia opcional del objeto, sin garantizar atomicidad ni durabilidad.

La operación que una respuesta verde podía exagerar

Un cliente envía la ruta antigua mediante RNFR. El servidor contesta 350 Requested file action pending further information. No es un error y, sin embargo, tampoco es el resultado final.

La RFC 959 define la familia 3xx como respuesta positiva intermedia. El mandato fue aceptado, pero la acción solicitada queda en suspenso hasta recibir más información. Para renombrar, esa información es el destino de RNTO.

La RFC 765 ya exigía que RNFR fuese seguido inmediatamente por RNTO. La primera orden señala el archivo; la segunda indica su ruta nueva. Solo juntas causan el cambio.

Un contexto retenido dentro de la conexión

FTP presenta el par como grupo secuencial. Una respuesta intermedia indica que los pasos anteriores tuvieron éxito suficiente para continuar. Si falla cualquier punto, la secuencia completa debe repetirse desde el comienzo.

El servidor retiene así una fuente pendiente dentro de la sesión de control. La especificación no entrega un identificador de transacción durable, no promete bloquear el archivo ni reservar el destino.

La relación depende también del orden. RNTO se aplica al archivo de la orden inmediatamente anterior; sin un RNFR válido puede recibir 503 Bad sequence of commands. Una auditoría debe conservar sesión, orden, ambas rutas y ambas respuestas. Dos eventos sueltos no demuestran una pareja.

Continuar no es completar

En la gramática de FTP, 2xx significa conclusión positiva. 250 dice que la acción de archivo terminó. 350 dice que falta información. Juntar ambos códigos en una categoría genérica de éxito borra el estado más importante.

Después de 350, el cliente sabe que puede suministrar el destino. Después del 250 de RNTO, sabe que el servidor declara completada la acción. Si se pierde esa respuesta final, el resultado queda incierto. La conducta segura es consultar el espacio de nombres antes de repetir, no tratar el viejo 350 como permiso de reanudar a mitad de una transacción.

La diferencia también importa a quien observa. Un medidor de intentos puede contar RNFR; un medidor de cambios debe esperar el resultado de RNTO. Son preguntas distintas.

Permiso sobre el objeto, permiso en el directorio

La RFC 3659 añadió los hechos MLSx. En perm, la letra f sobre un objeto indica que puede ser objeto de RNFR. La letra c sobre un directorio indica que allí pueden crearse nombres y que RNTO probablemente tendrá éxito.

El origen y el contenedor de destino son superficies de autoridad diferentes. Además, “probablemente” no significa reserva. El dato describe capacidades del usuario actual en ese momento; no congela políticas, elimina carreras ni sustituye la respuesta final.

Esta separación evita un error moderno: convertir permiso para actuar sobre una fuente en permiso para crear cualquier destino. Un privilegio único llamado “editar” suele ocultar las dos decisiones.

El objeto no tenía por qué ser su nombre

RFC 3659 definió también el hecho opcional Unique. Si dos rutas se refieren al mismo archivo subyacente, deberían compartir un token opaco; archivos distintos deberían usar valores distintos. La correspondencia debe mantenerse al menos durante la conexión de control.

Su ejemplo muestra mlst.c con un token, un RNFR respondido con 350, RNTO list.c respondido con 250 y, después, list.c con el mismo token. El nombre cambió; la evidencia acotada del objeto permaneció.

No es una identidad global ni perpetua, y los servidores no están obligados a ofrecer todos los hechos. El ejemplo no garantiza que toda implementación conserve el token. Sí demuestra una distinción conceptual: la respuesta acredita la operación y el token opcional puede reforzar la continuidad del objeto a través de dos nombres.

Mandato de protocolo, no promesa del sistema de archivos

La RFC 1123 mantuvo el par en los requisitos FTP. La RFC 5797 lo enumeró entre los mandatos base. El registro de IANA conserva las entradas.

Eso coordina vocabulario y clases. No demuestra soporte en un servidor concreto ni promete visibilidad atómica, sobrescritura, durabilidad, seguridad ante fallos o cruces entre sistemas de archivos. Esas propiedades viven bajo la frontera del protocolo y requieren otra evidencia.

La garantía más útil es más estrecha: el servidor debe distinguir un origen aceptado y pendiente de un cambio concluido.

El valor del estado intermedio

Los planos de control actuales también aceptan propuestas antes de ejecutarlas. El problema aparece cuando una interfaz llama “hecho” a “válido para continuar”.

Un diseño responsable nombra el estado pendiente, explica cuánto dura, qué lo cancela y qué respuesta prueba la confirmación. Separa autoridad de origen y destino, y no usa el nombre visible como único identificador del objeto.

El 350 era afirmativo porque el primer paso era válido. Era intermedio porque el cambio aún no existía. Las dos palabras eran necesarias.

Fuentes