On Tue, May 21, 2013 at 12:18:11PM -0400, Michael Johnson wrote:
> As I've been expanding my tests, I got to the point of synchronizing
> deleting a file and having that deletion propagate.  To do this, I ran
> csync2 -nr on one "node" to make sure that the presence of the file
> was recorded in the db, removed the file from that "node", ran csync2
> -nr again to record that the file was missing, and ran csync2 -u to
> try to synchronize it. Unfortunately, it is not being removed.
> 
> Here's the relevant segment of the test (when the test starts, a file
> named a/conflict exists and has been synchronized across all the
> nodes; testing conflict resolution succeeded):
> 
> remove_conflict()
> {
>         (
>         set -xe
>         # ensure that all content really conflicts
>         rm $1/a/conflict
>         )
> }
> assert_no_conflict()
> {
>         (
>         set -xe

Do you realize that set -e does NOT affect "lists",
but only "simple commands"?

>         for i in $* ; do
>                 [ -f $i/a/conflict ] && false

Do you realize that the exit code of the "list" above
will never be 0?

>         done

You realize that the exit code of a loop will be the exit code of the
last command that executed, so in this case will only be zero if
that function was called without arguments?


What you want is no set -e, it is misleading.
And probably no sub shell () either. What for?

Maybe:
 local i
 for i in $* ; do test -f $i/a/conflict && return 1; done


I'm not saying "notabug";
there may well be a genuine csync2 bug in that area as well.

I'm just pointing out that this implementation of the test is wrong.

>         )
> }
> TEST    "record conflict file on d2"    csync2 -C n2 -N $N2 -cr $D2
> TEST    "remove d2 conflict"    remove_conflict $D2
> TEST    "assert no conflict D2" assert_no_conflict $D2
> TEST_EXPECT_EXIT_CODE   1 "diff -rq D1D2 fail"  diff -rq $D1 $D2
> TEST    "record conflict file deletion" csync2 -C n2 -N $N2 -cr $D2
> TEST    "csync2 -uv inbound"    csync2_u ${N2}:n2 ${N1}:hub

your modified "csync_u" function is using the part after the : as
"config" (argument to the csync2 -C option)?

If so, you did not tell the "n2" config about this file,
or it's deletion.  csync2 -C n2 has not marked this file dirty,
so csync2 -C n2 -u won't propagate anything.

A "check" in one config will not set dirty flags,
or anything, really, for other configs.

That may be a design bug (or feature) of csync2,
but that's how it is:
different "-C config"s are completely independent,
they even use different databases.

> TEST    "assert no conflict D1" assert_no_conflict $D1
> That last test fails because the deletion of 2/a/conflict has not been
> propagated to deleting 1/a/conflict.
> 
> (Once that is completed, further tests ensure that the deletion gets
> pushed out to all the other spokes in my hub-and-spoke arrangement.)
> 
> I have read the man page, the current version of the paper, and some
> messages from the archives, and everything seems to imply that this
> should work. I'm not marking any nodes as slaves in their respective
> configurations.What other reasons might there be for deletions not
> being recognized and propagated?

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

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2

Reply via email to