¿Por qué rsync intenta copiar un archivo que ya está actualizado?

24

Tengo dos mismos archivos, en la máquina local y en la remota. Sus tamaños son iguales y el archivo en la máquina local es más nuevo que en el remoto, pero rsync aún intenta copiar el archivo.

Invoco rsync de la siguiente manera:

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

(si no uso la -nopción, inicia la operación de copia)

Los documentos de Rsync declaran explícitamente que no debería estar sucediendo:

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.

Salidas 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 qué pasó esto?

ACTUALIZAR:

Haciendo rsync --size-onlyresultados no se copian archivo:

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)
Rogach
fuente

Respuestas:

37

El algoritmo de verificación rápida considerará como modificado cualquier archivo que tenga un tiempo de modificación diferente o un tamaño diferente. Por lo tanto, si su directorio de destino tiene una versión más nueva del mismo archivo, se considerará diferente y se sincronizará con la versión de origen.

Ese es el comportamiento esperado (y más seguro). Por ejemplo, supongamos que tiene dos directorios, ~ / src y ~ / dest, cada uno con un archivo foobar. En ~ / src / foobar escribes "foo", y luego en ~ / dest / foobar escribes "bar". Ahora rsync ~ / src a ~ / dest. ¿Qué esperarías?

Ambos archivos tienen el mismo tamaño, pero el de ~ / dest es más nuevo. El comportamiento estándar de Rsync es reemplazar ~ / dest / foobar con ~ / src / foobar. Por supuesto, los archivos podrían ser idénticos y serían innecesarios, pero no hay forma de saberlo, a menos que haga una suma de comprobación o compare bit por bit.

Si no desea ese comportamiento, es decir, desea preservar los archivos más nuevos en el receptor, debe usar el indicador -u (--update).

-u, --update Esto obliga a rsync a omitir cualquier archivo que exista en el destino y tenga una hora modificada que sea más reciente que el archivo fuente. (Si un archivo de destino existente tiene un tiempo de modificación igual al del archivo de origen, se actualizará si los tamaños son diferentes).

Rafael Cavalcanti
fuente
2
Sí, de hecho era el problema. Olvidé agregar el -tindicador, por lo que no estaba configurando el tiempo de modificación adecuado en el nuevo archivo, y las invocaciones posteriores de rsync intentaban actualizar el archivo más nuevo. ¡Gracias!
Rogach
13
@Rogach Siempre use a rsync -amenos que tenga una buena razón para no hacerlo.
Gilles 'SO- deja de ser malvado'
Estaba teniendo el mismo problema con el OP, pero -aen este caso daría lugar a un problema diferente, a saber, un error. skipping directory .La causa fue que -acontiene -ry creo que si no hubiera directorios dentro de la carpeta, da ese error. Se discute en esta publicación de blog
cardamomo
@cardamom Uno aún debe usar -ade forma predeterminada, y luego deshabilitar explícitamente cualquier opción que incluya que no desee, con el --no-prefijo. En tu caso lo sería rsync -a --no-r.
Walf