[Csync2] Issue with the auto-backup feature. A bug?

[alex at gluu.org]

Greetings.

I'm a novice user of csync2, and just have built my first test cluster 
with it. However, I've encountered issue I haven't been able to find 
solution for yet. I installed csync2 using this package: 
http://oss.linbit.com/csync2/csync2-2.0.tar.gz I have quite a simple 
cluster setup of 2 nodes which try to replicate 1 directory with 1 file 
in it. Here is a sample config file:

nossl * *;
group cluster_group
{

         host host1.tst.com;
         host host2.tst.com;

         key /usr/local/etc/csync2/csync2.key;
         include /opt/testdir;

         exclude *~ .*;

         action
         {

                 logfile "/var/log/csync2_action.log";
                 do-local;
         }

         action
         {
                 pattern /opt/tomcat/conf/*;

                 exec "/sbin/service tomcat restart";
                 logfile "/var/log/csync2_action.log";
                 do-local;
         }

         backup-directory /var/backups/csync2;
         backup-generations 3;

         auto younger;
}

In my scenario I'm starting with this test file dirty and different on 
both hosts, thus in conflict. For example, I just running "csync2 -xvvv 
-N host1.tst.com" (I'm using -N key because of hostname is the same for 
both nodes, and different from the 2 names provided in "host" claim in 
config file; I'm using mappings in /etc/hosts to resolve these 2 
fictional dns names). I'm getting a lot of output, from which I see that 
it correctly detects that files differ and proceed to resolving the 
conflict. It says that it will uses younger/older method, than it tries 
to backup the file that needs to be overwritten (and it's actually 
creates this backup!), then it fails with some ambiguous error message, 
and keeps telling that "this file will remain dirty" from now on. File 
that should win the conflict (the one created later) is not changed

When I'm commenting out these 2 backup claims at the end of the config 
file - it works flawlessly.

Is it a bug, or am I missing something?

With best regards,
Alex.