> Author of the message didn't include rsync@lists.samba.org in the
reply,
> and I think this message is in topic.
Yes, thanks for cc'ing the rsync list. The net result of all this,
btw, was that I tried the patches Jim suggested and they didn't solve
the problem for me (I'm the guy who started the thread) -- rsync still
consistently hangs on large-ish directories.
scott
> -------- Original Message --------
> Subject: Re: rsync windows -> unix still hanging :(
> Date: Mon, 30 Dec 2002 17:24:47 -0800
> From: Jim Kleckner <jek_subs@kleckner.net>
> To: Mike Rubel <mrubel@galcit.caltech.edu>
> CC: cygwin@cygwin.com
> References:
> <Pine.GSO.4.10.10212301618100.1820-100000@betz.galcit.caltech.edu>
>
>
>
> The msleep(100) call is not checked into version 1.156 of main.c.
>
> I would recommend trying this one-line patch to see if it helps.
> I haven't personally delved into the true meaning.
>
> I just checked my read-only CVS tree for rsync again.
> Here is the context diff for that file. Note that the msleep(100)
> is not in the checked in version.
>
> Jim
>
> Index: main.c
> ==================================================================> RCS
file: /cvsroot/rsync/main.c,v
> retrieving revision 1.156
> diff -c -r1.156 main.c
> *** main.c 1 Aug 2002 20:46:59 -0000 1.156
> --- main.c 31 Dec 2002 01:21:34 -0000
> ***************
> *** 346,351 ****
> --- 346,353 ----
> exit_cleanup(0);
> }
>
> + io_start_buffering_in(f_in);
> + io_start_buffering_out(f_out);
> send_files(flist,f_out,f_in);
> io_flush();
> report(f_out);
> ***************
> *** 421,427 ****
> close(error_pipe[1]);
> if (f_in != f_out) close(f_in);
>
> ! io_start_buffering(f_out);
>
> io_set_error_fd(error_pipe[0]);
>
> --- 423,429 ----
> close(error_pipe[1]);
> if (f_in != f_out) close(f_in);
>
> ! io_start_buffering_out(f_out);
>
> io_set_error_fd(error_pipe[0]);
>
> ***************
> *** 434,440 ****
> write_int(f_out, -1);
> }
> io_flush();
> !
> kill(pid, SIGUSR2);
> wait_process(pid, &status);
> return status;
> --- 436,442 ----
> write_int(f_out, -1);
> }
> io_flush();
> ! msleep(100);
> kill(pid, SIGUSR2);
> wait_process(pid, &status);
> return status;
> ***************
> *** 476,481 ****
> --- 478,484 ----
> }
> }
>
> + io_start_buffering_in(f_in);
> if (delete_mode && !delete_excluded)
> recv_exclude_list(f_in);
>
> ***************
> *** 569,574 ****
> --- 572,578 ----
> extern int cvs_exclude;
> extern int delete_mode;
> extern int delete_excluded;
> + io_start_buffering_out(f_out);
> if (cvs_exclude)
> add_cvs_excludes();
> if (delete_mode && !delete_excluded)
> ***************
> *** 578,584 ****
> --- 582,591 ----
> if (verbose > 3)
> rprintf(FINFO,"file list sent\n");
>
> + io_flush();
> + io_start_buffering_out(f_out);
> send_files(flist,f_out,f_in);
> + io_flush();
> if (remote_version >= 24) {
> /* final goodbye message */
> read_int(f_in);
> ***************
> *** 590,595 ****
> --- 597,603 ----
> wait_process(pid, &status);
> }
> report(-1);
> + io_flush();
> exit_cleanup(status);
> }
>
>
>
> Mike Rubel wrote:
>
> >[ ... ]
> >
> >
> >
> >Could you clarify for me whether the patch Steve refers to is the same
as
> >(or has the same effect as) the one you describe below? Or are they
two
> >different animals? If they are different, should we test whether this
> >patch fixes his specific problem?
> >
> >Best regards,
> >Mike
> >
> >http://www.mikerubel.org
> >
>
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
>
>
>
>
>
>