Lars,
I apologise for pushing this one a bit fast but i feel it is better to get
the issue fixed in the trunk so that we do not have any PRIVATE changes in
our repository.
Further, having the patch committed to the trunk will give assurance the
fix is code reviewed and tested properly.
If you have any suggestions/corrections, then do let me know so that I can
incorporate those and submit an updated patch.
You may also suggest verifying specific test cases in order to ensure
better test coverage and avoid regression.
I really appreciate the fact that you and other commiters put extra efforts
on top on your normal day-job for making this software available to users
like us. I do know that it needs passion for the project and commitment for
open source.
I hope you would find some time amidst your busy schedule to review the
patch and commit it to the trunk.
Thanks and Regards,
Samba
PS:
Alternatively, how about inviting review comments from other users in the
community so that we can offload the efforts to some extent. I can guess
that many users would be needing a fix for the issue of 'sync failure
during subdir deletion' so those folks can take this patch and review if
possible or at least test and verify that it works for them. In this way we
can build an community over the project and ensure that every patch is
actually reviewed and tested well before getting committed to the trunk.
==================================================
On Mon, Jul 23, 2012 at 10:08 PM, Samba <saas...@gmail.com> wrote:
> Hi Lars,
>
>
> I noticed that the previous patch that I sent was only syncing the lowest
> level subdirectory [all files under it] in which one of the files matching
> the configured pattern have changed. It is not the parent directories even
> the parent directory is missing on the slave side.
>
> I tried something like:
>
> in update.c
>
> strncpy(temp,filename,filename_length+1);
>
> 349 do {
>
> 350
> get_parent_child_from_path(parent_dirname,NULL,temp);
>
> 351 csync_debug(0,"missing parent
> dir : %s; temp %s",parent_dirname, temp);
>
> 352
> strncpy(temp,parent_dirname,strlen(parent_dirname)+1);
>
> 353 conn_printf("SIG %s %s\n",
> url_encode(key), url_encode(temp));
>
> 354
> last_conn_status=read_conn_status(temp, peername);
>
> 355 } while(
> last_conn_status==CONNECTION_RESPONSE_PARENT_DIR_MISSING);
>
>
> in daemon.c
>
> if ( lstat_strict(filepath, &st) != 0 ) {
>
> 555 csync_debug(3,"error : %s
> while stating %s ",strerror(errno),filepath);
>
> 556 if ( errno == ENOENT ) {
>
> 557 struct stat sb;
>
> 558 char
> parent_dirname[strlen(filepath)];
>
> 559
> get_parent_child_from_path(parent_dirname,NULL,filepath);
>
> 560 if (
> lstat_strict(prefixsubst(parent_dirname), &sb) != 0 ) {
>
> 561
> conn_printf("OK (parent_dir_missing).\n---\noctet-stream 0 \n");
>
> 562 } else {
>
> 563
> conn_printf("OK (path_not_found).\n---\noctet-stream 0\n") ;
>
> 564 }
>
> 565 } else {
>
> 566 cmd_error =
> strerror(errno);
>
> 567 }
>
> 568 break;
>
> 569 } else if ( csync_check_pure(tag[2]) )
> {
>
> 570 conn_printf("OK
> (path_not_found).\n---\noctet-stream 0\n");
>
> 571 break;
>
> 572 }
>
>
> so that I can find the last available parent directory on the Slave
> server and can mark anything under that directory as dirty; but for some
> reason the slave does not return the message "OK (parent_dir_missing)" for
> the second "command/request". For the first SIG command it does indeed
> return "OK (parent_dir_missing)" but after that the response for second SIG
> is "---\n" which is strange. Is the csync protocol stateful and needs to be
> communicated in a particular order? If not, then can you please guide me as
> to what can be done to achieve what I'm expecting? i.e. repeatedly SIG the
> slave/peer for finding if the parent directory of a given path exists or
> if it is just the current path that is missing or the path exists but has
> contents different from that on master. If SIG is not the proper
> command/signal that needs to be used for this purpose, then do let me know
> which other command can work here.
>
> I think the only thing that needs to be done is find the last available
> parent directory from the path of the file to be synced and then mark all
> the files and subdirectories matching the configured patterns as dirty so
> that all these files and subdirs gets synced up with the peer in the next
> round of cron job.
>
>
> Thanks and Regards,
> Samba
>
>
>
> ===================================================================================
> On Thu, Jul 19, 2012 at 12:42 PM, Lars Ellenberg <
> lars.ellenb...@linbit.com> wrote:
>
>> On Tue, Jul 17, 2012 at 10:44:13PM +0530, Samba wrote:
>> > Hi Lars,
>> >
>> > I have updated the patch to also sync the complete directory tree, but
>> in
>> > the subsequent run.
>>
>> Thanks.
>>
>> Sorry for response times, swamped.
>> Though I should find some time for csync2 next week.
>>
>> > I tried to make it sync in the same run by trying to invoke
>> > csync_update_file_mod funtion but was getting "Format Error", so left it
>> > with syncing in the subsequent run by marking those children
>> > [files/folders] as dirty.
>> >
>> > I also made a minor fix related to creating the configured backup
>> directory
>> > instead of failing with an unrecognizable error message "Format Error".
>> >
>> > I'm confident that this patch makes csync2 more stabler and leavese very
>> > few chances of failing.
>> >
>> > I hope this patch gets approved and finally makes its way to the trunk
>> soon.
>> >
>> >
>> > Thanks and Regards,
>> > Samba
>> >
>> >
>> > PS:
>> >
>> > A note about handling deletes with auto-mode younger/older --- perhaps
>> we
>> > may not have a clean way of identifying whether the deletion on one
>> node is
>> > younger than a modification on the other node when we are relying on
>> > scheduled mechanism like cron but we would certainly be able to
>> distinguish
>> > when we integrate an inode eventing mechanism like lsync for populating
>> the
>> > "hints" table. I agree that we should keep it for future though.
>>
>> In that case you are talking about a tight race.
>>
>> If you call csync2 -u "occasionally" only, then conflicts can happen.
>>
>> But if you trigger it "immediately" (via inotify),
>> to have a conflict there,
>> you'd really need this to happen "simultaneously".
>>
>> Because usually, you'd have either the deletion first (and propagated),
>> and then not a modify, but a (re-)create (propagated).
>> Or you'd have the modify (also propagated),
>> and then a delete (propagated).
>>
>> So that would mean you really don't want to use csync2 as arbitrator
>> there, but fix your application to use some means of cooperation
>> ("locking"?) *outside* of csync2.
>>
>>
>> Lars
>> _______________________________________________
>> Csync2 mailing list
>> Csync2@lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/csync2
>>
>
>
_______________________________________________
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2
