DO NOT REPLY [Bug 4128] ignore-times with link-dest behaves unexpected / sematics not clear

samba-bugs at samba.org samba-bugs at samba.org
Thu Sep 28 09:44:19 GMT 2006


https://bugzilla.samba.org/show_bug.cgi?id=4128





------- Comment #1 from jwagner at computing.dcu.ie  2006-09-28 04:44 MST -------
Workaround
==========

For those who find this report while searching for a solution:

# clean up previous experiment
export B=192.168.0.20
ssh `whoami`@$B 'rm -f dst/data/*'
# run rsync with (default) quick check
rsync -av --link-dest=../ref/ data `whoami`@$B:dst/
# find out which files are wrong
md5sum data/*
ssh $B
md5sum dst/data/*
# delete these files on B
rm dst/data/text102.txt
exit
# rsync again without --link-dest to fill gaps
rsync -av data `whoami`@$B:dst/
# everything is now fine:
ssh `whoami`@$B 'ls -li dst/data/ ; cat dst/data/*'

Notes:
 * login on B in a 2nd terminal to calculate checksums in
   parallel
 * if there is a risk that file differences are hand-crafted
   to be invisible to MD5 (in recent years feasible ways of
   doing this have been published), you should use slower but
   more secure sha1sum or sha512sum
 * for more than just a small directory, use something like
   find -type f -print0 | xargs --null md5sum | sort -k2 >B.md5
   (see also "! -links 1" in 2nd bullet point below)
 * diff --speed-large-files A.md5 B.md5 should do fine in most
   cases to identify the differences
 * the only advantage over rsync --checksum is parallel checksum
   calculation; we are still wasting time on files that failed
   the quick check (time + size); improvement: generate file list
   with find -type f ! -links 1 -print0 on machine B and copy
   it to A (! means "not" for find)

BTW: I can confirm that rsync --checksum would work as expected:
ssh `whoami`@$B 'rm -f dst/data/*'
rsync -av --checksum --link-dest=../ref/ data `whoami`@$B:dst/
ssh `whoami`@$B 'ls -li dst/data/ ; cat dst/data/*'

Have fun,
Joachim


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list