APRENDER. PRATICAR. EVOLUIR.Definir uma origem e uma referência
O runner cria um ficheiro sintético de 234 256 bytes, uma área local e uma área servida por sftp-server. O cliente usa -D para comunicar diretamente com o processo local através de pipes. Não existe ligação SSH, autenticação, host key ou rede. A origem mantém-se estável durante os testes e o runner calcula hashes e compara bytes para verificar resultados. Esta preparação permite atribuir diferenças à operação testada. Num serviço real, a referência precisa de estar associada à versão e identidade da entrega, através do contrato e de uma origem confiável.
Retomar quando o prefixo corresponde
A primeira cópia parcial contém os primeiros 19 013 bytes da origem conhecida. O reget completa o destino e termina com zero. A comparação integral confirma que o ficheiro final corresponde à origem. O resultado mostra uma retoma correta sob condições controladas: origem estável e prefixo compatível. Não transforma o nome do ficheiro numa identidade de conteúdo. Antes de recuperar uma entrega real, identifica se a origem foi regenerada, se o parcial pertence à mesma versão e que verificação demonstra essa associação, sobretudo quando parceiros reutilizam nomes diários.
Observar sucesso técnico com conteúdo errado
O controlo negativo cria um parcial do mesmo comprimento, mas preenchido com bytes Z. O reget também termina com zero e produz 234 256 bytes. Porém, o prefixo errado permanece e só o sufixo corresponde à origem; o hash integral diverge. Assim, tamanho e saída zero passam nos dois testes, embora só um resultado esteja correto. O ensaio não corrompe qualquer ficheiro real. Demonstra com dados sintéticos que uma retoma pressupõe compatibilidade do conteúdo já existente e que o wrapper precisa de um critério de integridade adequado à entrega.
Separar staging de publicação
No teste de publicação, delivery.bin começa com uma versão anterior. O put escreve os dados novos em delivery.part, que o consumidor fictício deve ignorar. Depois dessa operação, o runner confirma o hash novo no parcial e o antigo no nome final. Só após rename o parcial desaparece e o nome final apresenta o conteúdo novo; um get confirma a igualdade dos bytes. Os registos mostram a extensão posix-rename anunciada e utilizada. A observação cobre estados antes e depois no mesmo filesystem, sem testar leitores concorrentes, falha de energia ou armazenamento.
Não transformar publicação em aceitação
A presença do nome final prova uma etapa técnica no ensaio, não uma reconciliação concluída. Define separadamente recebido, validado, publicado e aceite, com a ordem necessária ao contrato de cada sistema. Se uma confirmação se perde, o consumidor pode já ter processado a entrega. Consulta o identificador e o estado antes de repetir com outro nome, porque isso pode criar uma segunda entrega lógica. Nem um hash coincidente nem a semântica de rename fornecem execução única de negócio. O plano de recuperação deve indicar que evidência resolve a incerteza.
Decidir perto do cut-off
Num caso fictício de posições, o parceiro regenerou a origem, a retoma misturou versões e faltam dez minutos para o prazo. Suspende a publicação do conteúdo que falhou a comparação, confirma a versão pretendida e avalia uma transferência limpa ou outra recuperação autorizada. Comunica impacto e responsável pela decisão, sem alterar o hash esperado para fazer o resultado passar. O resumo é preservar identidade e integridade ao longo das etapas. A urgência muda a prioridade e a comunicação, mas não transforma uma cópia mista numa entrega válida.
# Actual local observations in content/labs/sftp-delivery/evidence.json
# validResume: exit 0, 234256 bytes, source hash matches
# wrongPrefixResume: exit 0, 234256 bytes, source hash differs
# publication: old final retained until rename; new final then matches
# No SSH transport or consumer is executedCaso fictício: dois reget terminam com zero e 234 256 bytes. Só o parcial com prefixo correto produz o hash da origem; a outra cópia fica impedida de ser publicada.
Armadilhas comuns
Aceitar tamanho e saída como integridade, retomar após regeneração sem reconciliar, ou considerar rename e hash como aceitação funcional.
Tópicos relacionados: Batch e falhas observáveis · Publicação e retoma de ficheiros · Diagnóstico e passagem para RUN
Uma retoma precisa de prefixo compatível; uma publicação precisa de conteúdo validado; uma entrega aceite precisa de evidência do consumidor.
Referência: OpenSSH SFTP client · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior