Comprueba la respuesta final de FTP antes de fiarte de una subida

Un cliente FTP puede aceptar una orden put mucho antes de que el servidor haya recibido el archivo, y la brecha entre esos dos sucesos es donde viven casi todos los misterios de la subida. Hay que completar cuatro etapas: se lee el archivo local, el servidor acepta la solicitud de almacenamiento, la conexión de datos transporta los bytes y la transferencia llega a una respuesta final positiva. Comparar las etapas es más útil que comparar clientes, porque un inicio de sesión que funciona y un nombre de archivo que aparece se quedan ambos antes del final.

Respuesta preliminar frente a respuesta final

Para STOR, una respuesta 125 o 150 es preliminar. Dice que el servidor está dispuesto a intentarlo y que se abre una conexión de datos, no que el objeto exista en su forma final. La operación solo se completa cuando la transferencia llega a una respuesta positiva de finalización, normalmente 226 o 250, en el contexto de esa operación.

Una 426 significa que la transferencia se abortó, y un número impreso por otra orden no es el resultado de esta subida. Lee la respuesta que pertenece al STOR, no el último número de la pantalla. Si el cliente sale antes de que llegue esa respuesta, no tienes ninguna prueba de finalización.

Conexión de control frente a conexión de datos

La autenticación y el listado de directorios usan la conexión de control. Los bytes usan una conexión de datos aparte, y su extremo se negocia para cada transferencia. Un inicio de sesión correcto demuestra la ruta de control y no dice nada sobre si la dirección de datos es alcanzable desde el cliente.

Cuando el servidor no puede abrir la conexión de datos, investiga el extremo negociado y la ruta permitida. El modo pasivo sigue exigiendo una dirección de datos y un puerto utilizables, y un cortafuegos o un dispositivo NAT entre cliente y servidor puede permitir la sesión de control mientras bloquea el rango de datos. Cuando el servidor rechaza la solicitud de almacenamiento, mira el nombre de ruta remoto, los permisos o los límites de almacenamiento. Ninguna de las dos ramas se explica porque la conexión de control se haya autenticado.

FTP sobre TLS frente a SFTP

FTP sobre TLS sigue siendo FTP: dos conexiones, respuestas FTP y una actualización a TLS en cada una. SFTP es un subsistema de SSH con una sola conexión y un conjunto de órdenes completamente distinto. Comparten un propósito y casi nada más, así que un diagnóstico que salta entre ellos suele empezar comparando los registros equivocados.

No desactives TLS para que un ayudante intermedio pueda inspeccionar la sesión, y no trates un fallo de SFTP como un problema de respuestas FTP. El manual de curl documenta TLS explícito, modo pasivo y opciones de subida si necesitas una prueba con script, y es la referencia de lo que cambia realmente cada opción.

Elige el protocolo que el servicio ofrece de verdad antes de depurarlo. Un servidor que solo habla SFTP nunca producirá una respuesta 226, por mucho que se configure el cliente.

Un nombre de archivo visible frente a un objeto almacenado

Un nombre de archivo visible puede representar un objeto incompleto, sobre todo tras una transferencia abortada o un cliente que salió antes de tiempo. Pide al propietario del servicio que compare el tamaño del archivo de prueba previsto y el hash de contenido de confianza con el objeto almacenado cuando se espera preservar los bytes.

Los modos binario y ASCII son otra comparación que cambia el resultado. El modo ASCII puede traducir los finales de línea, así que los bytes almacenados difieren del archivo local aunque la transferencia haya tenido éxito. Mantén el modo binario para una comprobación byte a byte, y no añadas opciones de conversión para que una transferencia fallida parezca distinta.

Un STOR normal puede sustituir un archivo existente, y el permiso para iniciar sesión o listar un directorio no establece el permiso para crear o sustituir un objeto en él. Usa para la prueba un nombre remoto no utilizado antes.

Qué comparar antes de reintentar

No añadas, no reanudes ni repitas una subida a ciegas sobre un archivo parcial incierto. Acuerda con el propietario si conviene reiniciar con un nombre nuevo, usar el procedimiento de recuperación admitido por el servicio o eliminar el objeto de prueba fallido.

Escribe el resultado como una de cuatro afirmaciones: la lectura local falló, se rechazó el almacenamiento, la transferencia de datos se abortó, o la transferencia se completó y los bytes almacenados coincidieron. Ese registro es un resultado más sólido que cambiar el intérprete, la VPN y los ajustes de FTP a la vez hasta que aparezca un nombre de archivo, y dice a la siguiente persona qué etapa inspeccionar. Guarda el texto de respuesta saneado junto con esa afirmación. Entonces un reintento es una decisión, no un reflejo.