Por que o rsync tenta copiar o arquivo que já está atualizado?


24

Eu tenho dois mesmos arquivos, na máquina local e na remota. Seus tamanhos são iguais e o arquivo na máquina local é mais recente que na remota - mas o rsync ainda tenta copiar o arquivo.

Invoco o rsync da seguinte maneira:

rsync -nv -e "ssh -p 2222" user@host:/data/file.fif data/file.fif

(se eu não usar a -nopção, ela iniciará a operação de cópia)

Os documentos do Rsync afirmam explicitamente que isso não deveria estar acontecendo:

Rsync  finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time.

Saídas de stat:

# remote file
  File: `data/fif/Skovorodko_Olga_45_raw.fif'
  Size: 1137551966  Blocks: 2221784    IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 286338      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1037/  platon)   Gid: ( 1047/  platon)
Access: 2013-08-08 18:40:16.907581658 +0400
Modify: 2013-07-16 12:01:09.158763284 +0400
Change: 2013-07-16 12:01:09.158763284 +0400

# local file
  File: `data/fif/Skovorodko_Olga_45_raw.fif'
  Size: 1137551966  Blocks: 2221792    IO Block: 4096   regular file
Device: 801h/2049d  Inode: 12987232    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1005/  platon)   Gid: ( 1003/  platon)
Access: 2013-08-08 19:02:57.146223369 +0400
Modify: 2013-08-08 19:02:57.146223369 +0400
Change: 2013-08-08 19:02:57.146223369 +0400

Por que isso acontece?

ATUALIZAR:

O rsync --size-onlyarquivo de resultados não está sendo copiado:

delta-transmission enabled
Skovorodko_Olga_45_raw.fif is uptodate
total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 14 bytes  received 114 bytes  85.33 bytes/sec
total size is 1137551966  speedup is 8887124.73 (DRY RUN)

Respostas:


37

O algoritmo de verificação rápida considerará como modificado qualquer arquivo que tenha tempo de modificação diferente ou tamanho diferente. Portanto, se o diretório de destino tiver uma versão mais recente do mesmo arquivo, ele será considerado diferente e será sincronizado com a versão de origem.

Esse é o comportamento esperado (e mais seguro). Por exemplo, vamos supor que você tenha dois diretórios, ~ / src e ~ / dest, cada um com um arquivo foobar. Em ~ / src / foobar, você escreve "foo" e, em ~ / dest / foobar, escreve "bar". Agora você rsync ~ / src para ~ / dest. O que você esperaria?

Ambos os arquivos têm o mesmo tamanho, mas o arquivo em ~ / dest é mais recente. O comportamento padrão do Rsync é substituir ~ / dest / foobar por ~ / src / foobar. Obviamente, os arquivos podem ser idênticos e desnecessários, mas não há como saber disso, a menos que você faça uma soma de verificação ou compare bit por bit.

Se você não deseja esse comportamento, ou seja, deseja que os arquivos mais recentes no receptor sejam preservados, use o sinalizador -u (--update).

-u, --update Isso força o rsync a ignorar qualquer arquivo existente no destino e ter um horário modificado mais recente que o arquivo de origem. (Se um arquivo de destino existente tiver um tempo de modificação igual ao do arquivo de origem, ele será atualizado se os tamanhos forem diferentes.)


2
Sim, era realmente o problema. Esqueci-me de adicionar -tsinalizador, por isso não estava definindo o tempo de modificação adequado no novo arquivo, e as chamadas subseqüentes do rsync estavam tentando atualizar o arquivo mais recente. Obrigado!
Rogach 8/08/13

13
@ Roger Use sempre, a rsync -amenos que você tenha um bom motivo para não fazê-lo.
Gilles 'SO- stop be evil' em

Eu estava recebendo o mesmo problema do OP, mas -a, nesse caso, levaria a um problema diferente, a saber, um erro. skipping directory .A causa foi a que -acontém -re acho que, se não houvesse diretórios na pasta, isso causaria esse erro. É discutido neste post do blog
cardamomo

@cardamom Um ainda deve ser usado -apor padrão e, em seguida, desabilitar explicitamente qualquer opção que você incluir, que você não deseja, com o --no-prefixo. No seu caso, seria rsync -a --no-r.
Walf 10/09
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.