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

Michael Tokarev mjt at
Fri May 14 01:54:44 MDT 2010

Hello.  This is my first post here ;)

I've been using rsync heavily for quite some time.
For one, we use it to perform offline backups of
numerous machines into single location.  Since the
systems are basically identical, it's wise to keep
only different files, hard-linking identical ones.
That worked well for many years, till rsync-3 were

The procedure is like this:

  on the server-to-be-backed-up there's a "previous"
  directory, which gets compared with "current"
  using rsync, to generate a batched update.
  That update, or "delta", is sent to the central
  server (backup destination).  There, it is applied
  to this system's "previous" state, to get the
  "current" one.

This alone works as expected.

The only difference between this version (which is
an intended usage) and my actual usage is that I add
extra --link-dest argument on the receiving end, to
simplify finding identical files.  So the receiving
end, unlike the sending one, has two --link-dests --
one usual for the "previous state", and one extra,
for "other machine" current state.

Example command lines:


   rsync -aHRSx \
    --link-dest=$last \
    --write-batch=batch \
    directory... \


   rsync -aHRS \
    --read-batch=batch \
    --link-dest=$other \
    --link-dest=$last \

So the only one additional option is given: extra
--link-dest=$other, for current backup dir of another

With this option, it fails on regular basis, in
batches on the same place.  Like this:

  (Skipping batched update for "etc/samba/smbpasswd")
  (No batched update for "etc/samba/smbpasswd")
  rsync error: some files/attrs were not transferred (see previous errors)
    (code 23) at main.c(1526) [generator=3.0.7]

Here are the files, with md5sums:

-rw------- 2 root root 6118 Mar 16 07:22 $other/etc/samba/smbpasswd
-rw------- 1 root root 6039 May 12 17:50 $last/etc/samba/smbpasswd
-rw------- 1 root root 6039 Май 14 10:35 $NEW/etc/samba/smbpasswd

where $NEW is the actual file being backed up, which
should be in the receiving batch.  Note that the new
file is of the same _size_ as in $other, but with
different content.

As you can see, $last and $new has the same content but
different timestamps.  I suspect it is due to some bug
in older rsync, or maybe some my inaccuracy - I don't
know, but the fact it that yes, some dates mismatches.
When I set the date for the $last to match the one in
the batch, it works.

But what is more interesting is that it also works when
I remove usage of the extra --link-dest, even with the
wrong timestamp.  It updates the timestamp and moves on.

But with extra --link-dest in place, it fails like the

To me it looks like the two places -- the one which
checks if the "batched update" is actually necessary
and the one which actually implements the update,
do not match each other somehow.

I'd say it's local operator/environment error, because
the destination is not the same as the sender expects,
if it were not working without the extra --link-dest.

And what I can say for sure is that it always worked
with rsync version 2.  I tried to switch to v3 for
serveral times, always ending up in this and reverting
back to v2.  Initially I tried updating rsync only on
the receiving side (with immediate problem being trivial
to fix by reverting back to v2 which processes the "bad"
batches just fine), now I updated it on both ends, so
v2 on the receiver does not work anymore, but the
problem is still the same.



More information about the rsync mailing list