O que você descreve é o comportamento correto para cp , não um bug. Dado o resultado que você está procurando, a modificação que você fez no seu script ( rm seguido por cp ) parece ser a abordagem correta.
Recentemente fui mordido por um mau comportamento em um script meu e fiquei me perguntando:
Essencialmente, o problema se resumia a isso. Primeiro, eu tinha uma estrutura de diretório existente com o layout a seguir.
/opt/dir/file.a /opt/dir/file.b /opt/dir/file em que file é um link físico para file.a . Eu queria substituir file por um script de shell que selecionou file.a ou file.b dependendo dos parâmetros, então eu corri algo assim:
cp my_file /opt/dir/file
O problema é que, como file é um link físico para file.a , (significando que os dois arquivos são realmente apenas dois nomes para o mesmo inode), a alteração foi refletida em file e file.a . Isso era obviamente não o que eu queria.
Parece que o comando cp abriu efetivamente /opt/dir/file com o sinalizador de arquivo truncado, algo como: fopen("file", "w+") . e escreveu para ele. Eu esperava que ele quebrasse o link físico desde que eu estava copiando um novo arquivo para esse nome.
Este é o comportamento correto e esperado de cp ? Parece não intuitivo para mim. Quando copio um arquivo de um local para outro, em minha mente, estou substituindo-o, não o reescrevendo. Existe um sinalizador para cp para evitar isso? Minha solução atual é que eu rm /opt/dir/file && cp my_file /opt/dir/file .
Olhando para a página de manual, aparece que cp --remove-destination my_file /opt/dir/file pode ser a solução correta, mas ainda estou interessado no que todos têm a dizer sobre o assunto.
O que você descreve é o comportamento correto para cp , não um bug. Dado o resultado que você está procurando, a modificação que você fez no seu script ( rm seguido por cp ) parece ser a abordagem correta.