Mengapa rsync mencoba menyalin file yang sudah terbaru?


24

Saya memiliki dua file yang sama, pada mesin lokal dan yang jauh. Ukurannya sama, dan file pada mesin lokal lebih baru daripada yang jarak jauh - tetapi rsync masih mencoba untuk menyalin file.

Saya memohon rsync sebagai berikut:

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

(jika saya tidak menggunakan -nopsi, itu memulai operasi penyalinan)

Dokumen Rsync secara eksplisit menyatakan bahwa itu tidak boleh terjadi:

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.

Output dari 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

Mengapa ini terjadi?

MEMPERBARUI:

Melakukan rsync --size-onlyfile hasil tidak disalin:

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)

Jawaban:


37

Algoritma pemeriksaan cepat akan mempertimbangkan modifikasi file apa pun yang memiliki waktu modifikasi berbeda atau ukuran berbeda. Jadi, jika direktori tujuan Anda memiliki versi yang lebih baru dari file yang sama, itu akan dianggap berbeda, dan itu akan disinkronkan ke versi sumber.

Itulah perilaku yang diharapkan (dan lebih aman). Sebagai contoh, misalkan Anda memiliki dua direktori, ~ / src dan ~ / dest, masing-masing dengan file foobar. Di ~ / src / foobar Anda menulis "foo", dan kemudian di ~ / dest / foobar Anda menulis "bar". Sekarang Anda rsync ~ / src ke ~ / dest. Apa yang kamu harapkan?

Kedua file memiliki ukuran yang sama, tetapi yang di ~ / dest lebih baru. Perilaku standar Rsync adalah mengganti ~ / dest / foobar dengan ~ / src / foobar. Tentu saja, file-file itu bisa identik dan tidak perlu, tetapi tidak ada cara untuk mengetahuinya, kecuali Anda melakukan checksum atau membandingkan bit per bit.

Jika Anda tidak menginginkan perilaku itu, artinya, Anda ingin agar file yang lebih baru dalam receiver dipertahankan, Anda harus menggunakan flag -u (--update).

-u, --update Ini memaksa rsync untuk melewatkan file apa pun yang ada di tujuan dan memiliki waktu modifikasi yang lebih baru dari file sumber. (Jika file tujuan yang ada memiliki waktu modifikasi sama dengan file sumber, itu akan diperbarui jika ukurannya berbeda.)


2
Ya, memang itulah masalahnya. Saya lupa menambahkan -tflag, jadi tidak mengatur waktu modifikasi yang tepat pada file baru, dan permintaan rsync berikutnya mencoba memperbarui file yang lebih baru. Terima kasih!
Rogach

13
@Rogach Selalu gunakan rsync -akecuali Anda punya alasan kuat untuk tidak melakukannya.
Gilles 'SO- stop being evil'

Saya mendapatkan masalah yang sama dari OP tetapi -adalam kasus ini akan mengarah ke masalah yang berbeda, yaitu kesalahan skipping directory .Penyebabnya adalah yang -aberisi -rdan saya pikir jika tidak ada direktori dalam folder itu memberikan kesalahan itu. Dibahas dalam posting blog ini
cardamom

@ cardamom One masih harus digunakan -asecara default, dan kemudian secara eksplisit menonaktifkan opsi apa pun yang termasuk yang tidak Anda inginkan, dengan --no-awalan. Dalam kasus Anda itu akan menjadi rsync -a --no-r.
Walf
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.