Como copiar um arquivo transacionalmente?

rsyncfaz esse trabalho. Um arquivo temporário é O_EXCLcriado por padrão (desativado apenas se você usar --inplace) e, em seguida, renamedsobre o arquivo de destino. Use --ignore-existingpara não substituir B se existir.

Na prática, nunca tive problemas com isso em montagens ext4, zfs ou mesmo NFS.

Não se preocupe, noclobberé um recurso padrão .

Você perguntou sobre NFS. É provável que esse tipo de código seja interrompido no NFS, pois a verificação noclobberenvolve duas operações NFS separadas (verificar se o arquivo existe, criar um novo arquivo) e dois processos de dois clientes NFS separados podem entrar em uma condição de corrida em que ambos são bem-sucedidos ( ambos verificam que B.partainda não existe, então ambos procedem para criá-lo com sucesso, como resultado, eles estão substituindo um ao outro.)

Não há realmente para fazer uma verificação genérica para saber se o sistema de arquivos no qual você está escrevendo suportará algo como noclobberatomicamente ou não. Você pode verificar o tipo de sistema de arquivos, se é NFS, mas isso seria uma heurística e não necessariamente uma garantia. Sistemas de arquivos como SMB/CIFS (Samba) provavelmente sofrerão dos mesmos problemas. Os sistemas de arquivos expostos através do FUSE podem ou não se comportar corretamente, mas isso depende principalmente da implementação.

Uma abordagem possivelmente melhor é evitar a colisão na B.partetapa, usando um nome de arquivo exclusivo (através da cooperação com outros agentes) para que você não precise depender de noclobber. Por exemplo, você pode incluir, como parte do nome do arquivo, seu nome de host, PID e um carimbo de data/hora (+possivelmente um número aleatório). garantem a exclusividade.

Então, qualquer um:

test -f B && continue  # skip already existing
unique=$(hostname).$$.$(date +%s).$RANDOM
cp A B.part."$unique"
# Maybe check for existance of B again, remove
# the temporary file and bail out in that case.
mv B.part."$unique" B
# mv (rename) should always succeed, overwrite a
# previously copied B if one exists.

Ou:

test -f B && continue  # skip already existing
unique=$(hostname).$$.$(date +%s).$RANDOM
cp A B.part."$unique"
if ln B.part."$unique" B ; then
    echo "Success creating B"
else
    echo "Failed creating B, already existed"
fi
# Both cases require cleanup.
rm B.part."$unique"

Portanto, se você tiver uma condição de corrida entre dois agentes, ambos prosseguirão com a operação, mas a última operação será atômica, portanto, B existe com uma cópia completa de A ou B não existe.

Você pode reduzir o tamanho da corrida verificando novamente após a cópia e antes da operação mvou ln, mas ainda há uma pequena condição de corrida. Mas, independentemente da condição de corrida, o conteúdo de B deve ser consistente, assumindo que ambos os processos estão tentando criá-lo de A (ou uma cópia de um arquivo válido como origem).

Observe que na primeira situação com mv, quando existe uma corrida, o último processo é quem vence, pois rename(2) substituirá atomicamente um arquivo existente:

Se newpath já existir, ele será substituído atomicamente, para que não haja nenhum ponto em que outro processo tentando acessar newpath o encontre ausente. [...]

Se newpath existir, mas a operação falhar por algum motivo, rename()garante deixar uma instância de newpath no lugar.

Portanto, é bem possível que os processos que consomem B no momento possam ver diferentes versões dele (diferentes inodes) durante esse processo. Se os escritores estão apenas tentando copiar o mesmo conteúdo, e os leitores estão simplesmente consumindo o conteúdo do arquivo, tudo bem, se eles obtiverem inodes diferentes para arquivos com o mesmo conteúdo, eles ficarão felizes da mesma forma.

A segunda abordagem usando um link físico parece melhor, mas me lembro de fazer experimentos com links físicos em um loop apertado no NFS de muitos clientes simultâneos e contando o sucesso e ainda parecia haver algumas condições de corrida lá, onde parecia que dois clientes emitiram um link físico operação ao mesmo tempo, com o mesmo destino, ambos pareciam ter sucesso. (É possível que esse comportamento esteja relacionado à implementação específica do servidor NFS, YMMV.) Em qualquer caso, esse é provavelmente o mesmo tipo de condição de corrida, onde você pode acabar obtendo dois inodes separados para o mesmo arquivo nos casos em que há simultaneidade entre escritores para acionar essas condições de corrida. Se seus escritores são consistentes (ambos copiando de A para B) e seus leitores estão consumindo apenas o conteúdo, isso pode ser suficiente.

Finalmente, você mencionou o bloqueio. Infelizmente, o bloqueio está em falta, pelo menos no NFSv3 (não tenho certeza sobre o NFSv4, mas aposto que também não é bom). cópias de arquivos reais, mas isso é perturbador, complexo e propenso a problemas como deadlocks, então eu diria que é melhor evitar.

Para obter mais informações sobre o assunto de atomicidade em NFS, você pode querer ler sobre o formato de caixa de correio Maildir , que foi criado para evitar bloqueios e trabalhar de forma confiável mesmo em NFS. Ele faz isso mantendo nomes de arquivos exclusivos em todos os lugares (para que você nem obtenha um B final no final).

Talvez um pouco mais interessante para o seu caso particular, o formato Maildir++ estende Maildir para adicionar suporte para cota de caixa de correio e faz isso atualizando atomicamente um arquivo com um nome fixo dentro da caixa de correio (para que possa estar mais próximo do seu B.) Acho que o Maildir++ tenta para anexar, o que não é realmente seguro no NFS, mas há uma abordagem de recálculo que usa um procedimento semelhante a este e é válido como uma substituição atômica.

Espero que todas essas dicas sejam úteis!

Você pode escrever um programa para isso.

Use open(O_CREAT|O_RDWD)para abrir o arquivo de destino, leia todos os bytes e metadados para verificar se o arquivo de destino é completo, caso contrário, existem duas possibilidades,

1. Gravação incompleta

2. Outro processo está executando o mesmo programa.

Tente obter um bloqueio de descrição de arquivo aberto no arquivo de destino.

Falha significa que há um processo simultâneo, o processo atual deve existir.

Sucesso significa que a última gravação falhou, você deve começar de novo ou tentar corrigi-lo gravando no arquivo.

Observe também que é melhor fsync()gravar no arquivo de destino antes de fechar o arquivo e liberar o bloqueio, ou outro processo pode ler dados que ainda não estão no disco.

https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks.html

Isso é importante para ajudá-lo a distinguir entre um programa em execução concorrente e uma operação travada por último.

Você obterá o resultado correto fazendo um cpjunto com mv. Isso substituirá "B" por uma nova cópia de "A" ou deixará "B" como estava antes.

cp A B.tmp && mv B.tmp B

atualização para acomodar existente B:

cp A B.tmp && if [ ! -e B ]; then mv B.tmp B; else rm B.tmp; fi

Isso não é 100% atômico, mas chega perto. Existe uma condição de corrida onde duas dessas coisas estão rodando, ambas entram no ifteste ao mesmo tempo, ambas veem que Bnão existe, então ambas executam o mv.

Você pode fazer isso criando um arquivo temporário adequado no diretório de destino, copiando esse arquivo temporário e vinculando o arquivo temporário ao destino, como estava fazendo na pergunta.

Isso depende apenas de linkat(2)ser atômico para o sistema de arquivos de destino

#!/bin/sh

ddir=$(dirname "$2")
tmpfile=$(mktemp --tmpdir="$ddir")
cp "$1" "$tmpfile" && ln "$tmpfile" "$2"
ret=$?
rm "$tmpfile"
exit $ret

Rsync é a ferramenta apropriada para usar, eu acho.

Você deve usar rsync -Pahn --checksum /path/from/source /destination/path

No entanto, tenha cuidado, os arquivos que você possui são muito grandes ...