O comportamento que você está observando acontece porque, embora o cliente tenha gravado dados no soquete para a conexão de dados FTP e o kernel do cliente respondeu que isso aconteceu com êxito (retornando com êxito da chamada de sistema write()
ou send()
), os dados ainda estão em todos os tipos de buffers e ainda não estão comprometidos com o arquivo de destino. É em buffers de rede no sistema operacional de origem, em buffers em placas ethernet, está em operação, está em buffers no destino, está nos buffers do processo do servidor FTP, foi gravado em um arquivo no servidor, mas não liberado para o disco, etc ...
Isso não acontece apenas com o FTP. Você pode facilmente perceber isso acontecendo com ferramentas de transferência de arquivos mais modernas, como scp
também. scp
um arquivo a meio do planeta (para uma rede de alta latência) ou para um sistema com armazenamento lento, e você verá que o progresso da transferência é mostrado mais rápido do que realmente é, então ele parece travar a 100% completo por um tempo antes que o comando seja realmente concluído.
Se você olhar o código-fonte para o netkit-ftp (o cliente FTP padrão / padrão no Debian), seu processamento de marca # não faz nada de especial. Ele grava as marcas de acordo com a quantidade de dados que gravou no soquete de conexão de dados. Assim, irá exibir o mesmo comportamento que você está observando.
O que os clientes FTP normais fazem e o que você deve fazer também é aguardar a resposta ao comando STOR
na conexão de controle. Esta resposta virá algum tempo depois que você já tiver liberado e fechado o soquete de conexão de dados. Quando você recebe essa resposta, você sabe que o servidor FTP tem os dados. Pode não estar totalmente comprometido com o disco por lá, mas isso é o máximo de confirmação que você receberá.