Comportamento inesperado de cp -a em links simbólicos

3

Ao copiar links simbólicos de backups incrementais, pode ocorrer um comportamento inesperado. Por exemplo:

# mkdir 0 1 2
# touch 0/a
# ln 0/a 0/b
# touch 1/a
# ln 1/b 1/a

Portanto, o diretório 0 parece com

a
b->a

E o diretório 1 parece

a->b
b

Agora corremos

# cp -a 0/. 2
# cp -a 1/. 2

O comportamento esperado / esperado seria que o diretório 2 seria indentical para 1 , mas na verdade ele contém dois links

a -> b
b -> a

Isso ocorreu na prática quando eu estava copiando alguns backups rsync de um diretório / usr /. O diretório / usr / share / zoneinfo passou por vários desses diversos switches de link simbólico no último ano. Parece que, embora cp -a não siga os links simbólicos em SOURCE, ele pode estar seguindo-os no DEST.

Existe uma maneira de obter o resultado apropriado aqui?

(Como um aparte, rsync faz isso corretamente, mas eu quero usar o sinal --reflink=always de cp também ...)

    
por process91 26.01.2017 / 04:48

1 resposta

2

Quando você faz cp -a 1/. 2 , ele está fazendo b primeiro, mas como b -> a já existe, o conteúdo de b é gravado em a . Então, a->b é considerado, o que resulta em sobrescrever a com o link simbólico a->b . Se você executar cp -a 1/. 2 novamente, deverá obter "Too many levels of symbolic links" .

Então, sim, cp segue os links simbólicos no destino. Você pode tentar --remove-destination , que resolve o problema corretamente para o seu MWE. No entanto, se você tiver links simbólicos como componentes de diretório no destino, eles não serão demolidos por --remove-destination .

A verdadeira questão é "por que fazer algo assim?" Eu só uso cp -a com um diretório vazio como destino. Além disso, os sistemas de arquivos que suportam --reflink=always também têm maneiras mais elegantes de clonar uma árvore de diretórios como backup.

    
por 26.01.2017 / 05:18

Tags