O documento está pronto, mas ainda não foi publicado
Um processo pode gerar corretamente um documento e falhar na passagem que o torna disponível. Se a investigação começar por reescrever o gerador, pode gastar esforço numa etapa que já funciona. É mais útil seguir a identidade do ficheiro, os seus bytes e a operação que separa preparação de publicação.
Este caso fictício acompanha um ficheiro de instruções de montagem, D-7. A revisão B foi aprovada para substituir a revisão A no destino de demonstração. Não há mudança no conteúdo aprovado durante a investigação, e nenhuma publicação real é realizada.
Comparar origem, destino e operação
O processo produz D-7-B na área de preparação, num sistema de ficheiros local identificado como F1. O tamanho e o resumo criptográfico correspondem ao documento aprovado. A revisão A continua completa no destino publicado, que pertence a outro sistema de ficheiros local, F2.
A aplicação tenta usar uma operação de mudança de nome para levar B diretamente de F1 para o endereço final em F2. No ambiente Linux do cenário, a operação devolve EXDEV. A inspeção confirma a fronteira entre os dois sistemas de ficheiros; não se trata de falta do documento nem de alteração do seu conteúdo.
O manual Linux de rename descreve essa limitação. A documentação de os.replace em Python também indica que a operação pode falhar entre sistemas de ficheiros. São contratos de operações específicas, não uma afirmação de que todo o movimento de ficheiros é impossível entre volumes.
Depois da falha observada, D-7-B permanece intacto em F1 e D-7-A permanece disponível em F2. O estado do trabalho deve dizer que a publicação não foi concluída. O facto de a geração ter terminado não autoriza marcar todo o percurso como concluído.
Preparar a substituição no destino
A correção escolhida preserva a revisão atualmente publicada enquanto prepara um ficheiro temporário próprio em F2. Copia B para esse temporário, sem expor o ficheiro incompleto como se já fosse o documento público. O nome temporário e os acessos pertencem ao processo de publicação autorizado.
Quando a cópia termina, a verificação compara tamanho e resumo criptográfico com a origem aprovada. A aplicação confirma também que está a tratar D-7-B e o destino combinado. Uma cópia completa do documento errado não seria um resultado aceitável.
Só depois desses controlos a operação suportada substitui o destino final a partir do temporário que já se encontra no mesmo sistema de ficheiros. A preparação e a decisão de publicação ficam distinguidas. O original de B é conservado até a conclusão estar confirmada, conforme o procedimento definido.
Não se resolve o problema apagando primeiro a revisão A e esperando que a cópia seguinte funcione. Essa sequência criaria um período sem o documento disponível e tornaria uma falha de cópia num problema maior.
Concluir o percurso e observar a falha de controlo
No registo fictício aceite, a nova preparação em F2 termina com os mesmos bytes de D-7-B. A substituição é concluída e uma nova abertura do destino final apresenta a revisão B correta. O estado de publicação identifica essa revisão; o histórico conserva a anterior como previsto no exercício.
Um segundo ensaio interrompe a cópia antes de esta estar completa. O temporário não passa na verificação e não é publicado. A versão que já estava disponível continua intacta, e a origem aprovada mantém-se para recuperação. O temporário incompleto é tratado segundo a limpeza prevista, sem apagar ficheiros de outros trabalhos.
Um documento independente, D-8, conserva o conteúdo, o destino e o estado originais. Este controlo ajuda a verificar que a correção usa a identidade da tarefa e não uma procura ampla por «o último ficheiro» numa pasta partilhada.
O teste também mantém uma recusa de permissão como falha. Não remove controlos de acesso para fazer a publicação passar. Uma mudança na autorização necessária deve ser avaliada separadamente.
Delimitar o que foi demonstrado
A substituição atómica, quando suportada e concluída no contrato indicado, diz respeito à passagem do nome de destino para o novo ficheiro. Não demonstra por si só durabilidade perante uma falha de energia, recuperação de todos os metadados ou comportamento idêntico num sistema de ficheiros remoto. Essas necessidades exigem desenho e verificação próprios.
O caso usa dois sistemas locais e uma única publicação autorizada. Processos concorrentes, permissões, espaço disponível e conservação de revisões precisam de ser considerados conforme a aplicação real. O ensaio limitado não deve ser apresentado como certificação de todo o serviço documental.
Guardar a investigação que permite manter a correção
Registe as áreas de origem e destino, a operação que falhava, os controlos da cópia e a condição que permite publicar. Inclua uma falha deliberada da cópia e um documento independente nas verificações futuras. Assim, uma alteração de alojamento não elimina inadvertidamente a razão da etapa temporária.
O serviço de automatização pode tratar este tipo de passagem, e a manutenção pode investigar um processo existente. Para iniciar a conversa, descreva a última etapa que foi realmente concluída e a informação que prova esse resultado.