On Fri, Oct 30, 2015 at 06:11:59PM +0100, Erik wrote:
> I am currently using csync2 2.0 to synchronize files between two
> different computers. They are set up so they can reach each other and
> duplicate the files as they should. The problem I get is that whenever a
> file has been duplicated, it isn't removed from the dirty list. Running
> csync2 manually produces a long list of files that is going to be tested
> against the other computer. Every file fails with message:
> Do not auto-resolve conflict: Lost 'younger/older' test.
> File stays in dirty state. Try again later...

If it is *the same* date,
it is neither younger nor older, no auto-resolve will be done,
you'll get the above message, and need to resolve by hand.

Not saying that this is optimal,
just stating how it is.

> Running csync2 on the other computer produces the exactly same list with
> the same errors.
> Also deleting a file does not work as expected as csync2 re-creates it

maybe not as expected, but as documented.
        The younger, older, bigger and smaller methods
        let the remote side win the conflict
        if the file has been removed on the local side.

csync2 has no way of knowing when a file was deleted.  It cannot know if
the deletion happened before or after the creation on the other node.
And it does not like to automate data loss.
So yes, to get rid of a file that was deleted on one node,
but was created/changed/modified/touched on some other node,
you will have to remove it *again*, and synchronize that event *soon*,
before some other guy touches that file again.

You may also need to check what file system and kernel is in use,
and if your file systems support sub-second time stamps.

Because, csync2 does not (at least not properly) do that. :-(
And comparing time stamps where some entities compare nanoseconds,
and others truncate to seconds can get messy.
So that may be one aspect of whatever issue you really have there.

> on the computer during the next syncing. Deleting the file on both
> computers solves the problem but not how csync2 handles the database of
> dirty files.
> Interestingly is that when csync2 2.0 sync with csync2 1.34, the dirty
> table empties accordingly with message:
> File is already up to date on peer.
> It does not matter which computer I run csync2 on. It just works.

: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA  and  Pacemaker support and consulting

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
Csync2 mailing list

Reply via email to