skipping and not finding batched updates with extra --link-dest?

Wayne Davison wayned at
Sat May 29 11:03:48 MDT 2010

On Fri, May 14, 2010 at 12:54 AM, Michael Tokarev <mjt at> wrote:

> I add extra --link-dest argument on the receiving end, to simplify finding
> identical files.

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'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.

For a batch update, you should have an identical set of files for the
batch-creation and batch-replay hosts.

If you'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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rsync mailing list