Perché rsync tenta di copiare un file che è già aggiornato?

Ho due stessi file, sul computer locale e su quello remoto. Le loro dimensioni sono uguali e il file sul computer locale è più recente di quello remoto, ma rsync tenta comunque di copiare il file.

Invoco rsync come segue:

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

(se non utilizzo l' -nopzione, avvia l'operazione di copia)

I documenti Rsync dichiarano esplicitamente che non dovrebbe accadere:

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.

Uscite da 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

Perché succede?

AGGIORNARE:

Il rsync --size-onlyfile dei risultati non viene copiato:

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)

rsync

— Rogach
fonte

L'algoritmo di controllo rapido considererà modificato qualsiasi file con tempi di modifica o dimensioni diverse. Pertanto, se la directory di destinazione ha una versione più recente dello stesso file, verrà considerata diversa e verrà sincronizzata con la versione di origine.

Questo è il comportamento previsto (e più sicuro). Ad esempio, supponiamo di avere due directory, ~ / src e ~ / dest, ognuna con un file foobar. In ~ / src / foobar scrivi "foo", e poi in ~ / dest / foobar scrivi "bar". Ora rsync ~ / src su ~ / dest. Cosa ti aspetteresti?

Entrambi i file hanno le stesse dimensioni, ma quello in ~ / dest è più recente. Il comportamento standard di Rsync è quello di sostituire ~ / dest / foobar con ~ / src / foobar. Naturalmente, i file potrebbero essere identici e sarebbero inutili, ma non c'è modo di saperlo, a meno che non si faccia un checksum o si confronti bit per bit.

Se non si desidera tale comportamento, vale a dire che si desidera conservare i file più recenti nel ricevitore, è necessario utilizzare il flag -u (--update).

-u, --update Questo forza rsync a saltare qualsiasi file esistente sulla destinazione e con un orario modificato più recente del file sorgente. (Se un file di destinazione esistente ha un tempo di modifica uguale al file di origine, verrà aggiornato se le dimensioni sono diverse.)

— Rafael Cavalcanti
fonte

Sì, era davvero il problema. Ho dimenticato di aggiungere il -tflag, quindi non stava impostando il tempo di modifica corretto sul nuovo file e le successive invocazioni rsync stavano cercando di aggiornare il file più recente. Grazie!

— Rogach

@Rogach Utilizzare sempre a rsync -ameno che non si abbia una buona ragione per non farlo.

— Gilles 'SO- smetti di essere malvagio'

Stavo riscontrando lo stesso problema dell'OP, ma -ain questo caso si sarebbe verificato un problema diverso, vale a dire un errore skipping directory .La causa era che -acontiene -re penso che se non ci fossero directory all'interno della cartella che dà quell'errore. Viene discusso in questo post sul blog

— cardamomo il

@cardamom Uno dovrebbe ancora usare -aper impostazione predefinita, quindi disabilitare esplicitamente qualsiasi opzione che include che non si desidera, con il --no-prefisso. Nel tuo caso lo sarebbe rsync -a --no-r.

— Walf,