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

[Michael Tokarev]

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

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:

  sender:

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

  receiver:

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

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

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
e473d16a8abad10a3f08e3fa96b5ed37
-rw------- 1 root root 6039 May 12 17:50 $last/etc/samba/smbpasswd
d7bc141404920cd330f1ae0aff96389f
-rw------- 1 root root 6039 Май 14 10:35 $NEW/etc/samba/smbpasswd
d7bc141404920cd330f1ae0aff96389f

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

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.

Thanks!

/mjt