APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um consumidor que lê assim que encontra o nome final pode observar um ficheiro ainda em construção. Acorda uma área ou nome temporário ignorado e um passo de publicação depois da validação. Se esse passo usar rename, verifica implementação, extensão e filesystem. A extensão OpenSSH posix-rename tem semântica POSIX distinta da operação básica de versões do protocolo; não afirmes atomicidade universal para qualquer servidor SFTP. No caso POSIX documentado, origem e destino têm de estar no mesmo filesystem. Copiar entre filesystems não preserva automaticamente as mesmas propriedades. O contrato do consumidor deve indicar quando pode começar e como identifica cada entrega.
Aplicação guiada
Retomar uma transferência também tem pressupostos. Se a origem foi regenerada e o prefixo mudou, continuar sobre a cópia parcial antiga pode combinar versões incompatíveis. Reconcilia o conteúdo antes de decidir retoma ou nova entrega. Flush após upload depende de suporte e resultado da extensão fsync no exemplo OpenSSH; persistência em armazenamento não prova validação ou processamento de negócio. Num cenário de reconciliação, separa os marcos de ficheiro recebido, publicado, validado e aceite. Se a resposta se perder após publicar, conserva a identidade da entrega e consulta o estado do consumidor antes de repetir. Encriptação do transporte não fornece processamento exatamente uma vez.
Ficheiro persistido e ficheiro aceite pelo negócio são marcos diferentes.
Armadilhas comuns
Nome final como pronto; rename universal; retoma com origem alterada; flush como reconciliação; timeout como ausência de efeito.
Tópicos relacionados: Transporte e confiança no servidor · Permissões e isolamento · Batch e falhas observáveis
Define publicação e recuperação como contratos explícitos entre produtor e consumidor.
Referência: OpenSSH implementation protocol extensions · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior