vantagens do link físico do arquivo sobre a cópia do arquivo

Question

Eu tenho um script de shell Bourne que aceita um único argumento (arquivo de texto geralmente com poucos KB de tamanho). Essencialmente, esse script é um wrapper para scp , que copia esse arquivo de texto para o servidor remoto. O script não tenta scp do arquivo original, mas faz um link físico ou uma cópia desse arquivo:

#!/bin/sh

TRANSFER_FILE=/var/tmp/acc_transfer_link_$$
INPUT_FILE=$1

#  Linking is always a better option, so try it first
ln $INPUT_FILE $TRANSFER_FILE 2>/dev/null

RC=$?
if [ $RC -ne 0 ]; then
  cp $INPUT_FILE $TRANSFER_FILE
fi

O autor deste script deixou um comentário:

Linking is always a better option, so try it first

Por que isso acontece? É porque copiar demora um pouco mais do que criar um link físico? Qualquer outro motivo?

    

Answer 1

Depende.

Criar um link é mais rápido do que copiar os dados, mas o arquivo resultante terá o mesmo conteúdo do original, e qualquer modificação será mostrada em ambos. Se isso é vantagem ou não, depende do motivo pelo qual o link / cópia foi feito. Além disso, os links físicos funcionam apenas no mesmo sistema de arquivos, portanto, se /var ou /var/tmp for uma montagem separada do diretório de origem, a vinculação não funcionará.

Mas eu me pergunto qual é o caso de uso aqui. Se o propósito do script é copiar o arquivo nomeado em $1 , por que fazer uma cópia para $TRANSFER_FILE em vez de apenas executar scp no arquivo original diretamente? Tomando uma cópia local primeiro só deve ser necessário se houver motivos para supor que o arquivo de origem pode ser modificado durante a cópia, e o arquivo não deve ser copiado em um estado inconsistente. Mas a abordagem aqui tem alguns problemas:

1) fazer uma cópia local com cp tem o mesmo problema: a origem também pode ser modificada durante a cópia local. 2) a vinculação com ln seria instantânea, mas como o link físico aponta para os mesmos dados do original, qualquer processo que abrisse o arquivo antes do link poderia continuar a modificar os dados.

É necessário verificar se o arquivo não está aberto em outro processo após o link (usando algo como lsof ) ou fazer uma cópia e verificar a consistência dos dados por algum método específico do aplicativo. Já que nem é tão simples, a maneira usual de fazer modificações atômicas é escrever uma nova cópia do arquivo e renomeá-la sobre a antiga. Dessa forma, todos os processos que abriram o arquivo antes da renomeação receberão a versão antiga e todos os processos que a abriram após a renomeação receberão a nova versão. Mas nenhum deles verá uma cópia incompleta. Isso tem que ser feito quando o arquivo é modificado, no entanto, não no programa de leitura do arquivo.