On Sat, 2002-05-18 at 01:32, John D. Hendrickson wrote:
> Debian r2.5 (Potato)
> rsync version 2.3.2 protocol version 21
> ( the latest stable deb version anyway :)
>
> RE: absolutely older file keeps getting chosen for update
This could be some sort of NFS bug, but you might want to tr
[resent by mbp]
On Tue, 2002-05-28 at 10:22, Jonathan Kamens wrote:
> If you run rsync with a subshell through ssh.com's ssh and sshd and
> then kill the client with ctrl-C, the rsync server process running on
> the remote machine grows without bound and eventually completely hoses
> the machine
On Thu, 2002-04-11 at 05:01, Diburim wrote:
> rsync processes hang and client failing on "max connections",
> I can't kill rsync process.
[ ... ]
> rsync is started from inetd
> rsync version on the server 2.5.2 clients are 2.5.2 and 2.5.4
Sounds like a bug that was fixed in 2.5.4. Could you
Check out rdiff-backup. I have been very, very impressed with how easy
it is to use. It uses the same algorithm as rsync to create incremental
diffs.
http://www.stanford.edu/~bescoto/rdiff-backup/
(also packaged for Debian, in the 'rdiff-backup' package)
--
To unsubscribe or change option
On Mon, 2002-02-18 at 17:53, Martin Pool wrote:
> On 18 Feb 2002, Wayne Davison <[EMAIL PROTECTED]> wrote:
> > On Mon, 18 Feb 2002, Martin Pool wrote:
> > > Why the sleep() call?
>
> I guess the point is that the fork() probably failed because the
> server is overloaded, and therefore there is no
Hello,
Rsync maintainers, could you evaluate the patches in Debian bugs #129135
and #124286? #129135 seems straightforward enough.
They are accessible at:
http://bugs.debian.org/129135
and
http://bugs.debian.org/124286
Also, I haven't gotten an evaluation of my patch for #128632 (previously
s
I noticed we're not checking for a failure to fork() in socket.c. This
patch should address the problem.
Index: socket.c
===
RCS file: /cvsroot/rsync/socket.c,v
retrieving revision 1.54
diff -u -u -r1.54 socket.c
--- socket.c
Hello,
The attached patch should fix Debian bug #128632
(http://bugs.debian.org/128632). This bug happened because if an error
occurred in writefd_unbuffered (such as the remote end closing the
socket), it would call rprintf, which would call io_multiplexing_write,
which would in turn call write
On Wed, 2002-01-02 at 17:29, Dave Dykstra wrote:
> Isn't there some solution that doesn't have to explicitly list every
> variable name? I think that's asking for future bugs; just because there's
> an instruction in a comment doesn't mean people will remember to do what
> it says when they add a
On Tue, 2002-01-01 at 19:45, John Malmberg wrote:
>
> The config.h.in template file is missing the line:
>
> #undef HAVE_INET_NTOP
At least this one is fixed in rsync CVS, as I discovered when I ran into
the same bug. Dunno about the rest.
rsync maintainers: could we have a new release soon?
Hi, I spent a little bit of time trying to debug a segfault in rsync
2.5.0, and after discovering it was in loadparm.c, I noticed that the
bug had been worked around in the current CVS by removing a free()
statement.
That fix seems less than optimal; here's a patch which should fix the
memory lea
11 matches
Mail list logo
