Por que o rsync copia arquivos depois de copiá-los manualmente?

Por que o rsync copia arquivos depois de copiá-los manualmente?

Copiei muitos arquivos em muitas pastas (~ 54 GB) de um local ext4 para outro no cp ~/1 ~/2 -d -r -v -ibash. Eu queria então verificar se todos os arquivos foram copiados corretamente, então executei rsync --delete -vturOn ~/1 ~/2, mas o rsync queria copiar todos os arquivos. Por que é isso?

PS: Pretendia usar cpwith -a, mas usei -derroneamente.

Editar: uma respostaaquime levou a usar o --itemize-changessinalizador que me mostra >f..t......todos os arquivos. A página man indica que os ttempos de modificação dos meios são diferentes, o tipo de arquivos é um arquivo ( f) e apenas os atributos do item estão sendo modificados ( .). Isso está correto? Então tudo o que vai mudar são os tempos de modificação?

Editar: executei o rsync(sem o -n) e apesar dos ttempos de modificação serem diferentes, ele copiou todos os arquivos novamente (o conteúdo real do arquivo), o que é inesperado porque o rsync deve fazer uma cópia diff de qualquer maneira, o que deve ser observado?

Editar: interrompeu a sincronização e repetiu sem o -tparâmetro. Agora as alterações discriminadas mostravam 'T' em vez de t. Parece que terei que copiar todos os arquivos via rsync pelo menos uma vez se quiser usar o rsync nesses arquivos no futuro.

Editar: apaguei os arquivos de destino e copiei tudo novamente com rsync com -vanparâmetros.

Responder1

Da documentação do rsync:

O Rsync encontra arquivos que precisam ser transferidos usando um algoritmo de “verificação rápida” (por padrão) que procura arquivos que mudaram de tamanho ou na hora da última modificação.

Além disso, quando a origem e o destino são locais, rsyncé executado com a --whole-fileopção por padrão.

-W, --whole-file

Com esta opção, o algoritmo de transferência delta do rsync não é usado e, em vez disso, o arquivo inteiro é enviado como está. A transferência pode ser mais rápida se esta opção for usada quando a largura de banda entre as máquinas de origem e de destino for maior que a largura de banda para o disco (especialmente quando o "disco" for na verdade um sistema de arquivos em rede). Este é o padrão quando a origem e o destino são especificados como caminhos locais, mas somente se nenhuma opção de gravação em lote estiver em vigor.

Não tenho certeza, mas parece que você pode querer a --checksumopção.

-c, --checksum              skip based on checksum, not mod-time & size

Observe que isso requer a leitura dos arquivos de origem e de destino do disco para calcular a soma de verificação.

Mais sobre isso:

https://superuser.com/a/118984/219809

https://serverfault.com/a/279346

informação relacionada