<div class="gmail_quote">On Fri, May 14, 2010 at 12:54 AM, Michael Tokarev <span dir="ltr">&lt;<a href="mailto:mjt@tls.msk.ru">mjt@tls.msk.ru</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I add extra --link-dest argument on the receiving end, to simplify finding identical files.</blockquote><div><br></div><div>That is not supported because it can radically change what rsync is doing.  You may have an update in the batch file that is based on a different basis file than the one that rsync found on the receiving side, which could (attempt to) corrupt the file or cause other problems.  With the --hard-link (-H) option, it can move the file&#39;s update around since it can change when rsync figures out that a file with multiple hard links is not going to be found elsewhere in the transfer.</div>
<div><br></div><div>For a batch update, you should have an identical set of files for the batch-creation and batch-replay hosts.</div><div><br></div><div>If you&#39;re wanting to find more files to hard-link together, you should probably do some kind of post-processing work.  For instance, in 3.1.0dev (the upcoming release) there is a %C escape for the --out-format option that would output the md5 sum of every file in the transfer.  If you had a list of the current md5 sums on the disk, you could match them and hard-link them together, updating the list with the new checksums.  Or you could create something that scans through the parallel hierarchies looking for matching name+mtime+size entries.</div>
<div><br></div><div>As for rsync 2 working with that idiom, it might be caused by a bug-fix in the hard-linking code, or perhaps by some bug-fixing to the batch code, or something similar.  Rsync 2 might just be getting lucky, or it might be silently doing the wrong thing.</div>
<div><br></div></div>..wayne..<br>