Add methods for auto resolve deletions

[bes-internal]

Docs said https://github.com/LINBIT/csync2/blob/master/doc/csync2.adoc#conflict-detection:

The younger, older, bigger and smaller methods let the remote side win the conflict if the file has been removed on the local side.

Maybe add some parameter just for auto resolve for deletetion? auto-delete (yes|no)?

refs:

1. http://lists.linbit.com/pipermail/csync2/2009-August/000571.html
2. #8

[lge]

so if any side removes the file, it shall be removed everywhere, even if modified there since the last check? sounds dangerous. But yes, anyone, please feel free to implement an option to never/always propagate deletions...

Say you have three nodes, one with no change, one with some change, and one with a deletion. Define what you want to happen:

• if the "change" side tries to sync first
• if the "deletion" side tries to sync first and see how you can achieve that.

[bes-internal]

Since csync2 works on the "push" principle we can build tables like this (for csync2 v2.0):

↓ push side \ listen side →	■ no changes	▲ some changes	🞫 deletion
■ no changes	-	-	-
▲ some changes	Win	Challenge/Win	Win
🞫 deletion	Fail (with auto not left/right) (should Win with auto-delete=yes)	Fail (with auto not left/right) (should Win with auto-delete=yes)	-

Where Win - do copy action Fail - still in conflict

P.S. This option should probably be called auto-force-delete

[ggs67]

I pick this up as I have plans to work the "auto" topic. Adding a separate auto-delete may be contra-productive (but nor excluded yet) in this context. My plan is to modify the auto syntax so that it accepts a set of options allowing it to be applied to fil patterns for example like:

auto left for *.conf if "/usr/local/bin/some-script.sh"

and may consider a delete=

But like Lars did already pointed out this is quite dangerous and needs thinking. For instance in the table above I would discourage the fact that auto-delete=yes would simply win in both cases (modified or not) and fail otherwise (except left/right). This is introducing one strong option and removing today's intelligence about deletion (at least to my understanding).

So I would add more granularity delete= never | keep[-always] (or restore) | always | normal (or standard) | possibly others...

never : never delete any matching file (warn about missing) keep : copies existing file top missing one always: missing file always wins -> delete other hosts file (modified or not) normal (default): honor auto method left/right or may not resolve conflict in others (if the file was modified)