similar to: [PATCH] Infinite recursion in rsync --server

Here's a resend of an old patch that is intended to avoid an infinite recursion (ending in a stack overflow) of the rwrite() function getting an error that calls rwrite(), ad naseum. I've only seen this happen when one of the sides dies due to a program error -- in that case, the connection is closed, and when we try to send an error to the other side and it generates an error, the error

(As I was composing this, the 2.6.1 release notice on the rsync list rolled in. The quoted source, below, hasn't changed, so I'll leave the 'pre-1' references unchanged...) I have a situation where an error message seems to be sent from the daemon to the client, but none is logged in the daemon's log. Daemon is 2.6.1pre-1, with --timeout=3600, light CPU load. Client is

(problem encountered on Tru64Unix v4.0f with rsync 2.5.5) A failure to write to stdout or stderr in rwrite (log.c:279) will trigger an endless loop as follows: 0 rprintf calls rwrite 1 rwrite calls fwrite 2 fwrite fails 3 rwrite calls _exit_cleanup 4 _exit_cleanup calls log_exit 5 log_exit calls rprintf 6 rprintf calls rwrite 7

-----BEGIN PGP SIGNED MESSAGE----- I added the following code to log_exit(): void log_exit(int code, const char *file, int line) { static int error_count=0; if(error_count++ > 10) { abort(); } To force it to bail earlier instead of overflowing the stack. As you can see at frame #50, it is trying to log that the connection went away unexpectantly.

Hi everybody, I use rsync v2.5.5 almost without problems, but it dumps core from time to time. Core was generated by `rsync'. Program terminated with signal 11, Segmentation fault. There is excerpt from gdb's bt: #0 0x2810106f in __sfvwrite () from /usr/lib/libc.so.4 #1 0x280fdfe1 in fprintf () from /usr/lib/libc.so.4 #2 0x281002b6 in vfprintf () from /usr/lib/libc.so.4 #3

(I am not on the rsync mailing list, so if you send a response to this message to the list, please be sure to CC me.) I first reported this bug go Red Hat in <URL:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65350>. 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

This mode is useful when a process is monitoring the log for post-processing of transferred files. With --log-after in local mode, both sender and receiver log to the same log file, so it require --log-file with absolute path. We add %o to the default log format, so it will be easy to tell the logs of the sender from the logs of the receiver: 2023/02/14 14:40:25 [559755] building file list

-----BEGIN PGP SIGNED MESSAGE----- The FreeSWAN project uses rsync to keep our FTP repository up-to-date. The FTP server is at xs4all.nl, and we rsync to one of their FreeBSD boxes (xs1.xs4all.nl) over SSH. We have been experiencing core dumps from the remote rsync. Initially this was with the XS4ALL provided rsync in /usr/local/bin/rsync. Since I didn't have access to the source code for

Hello - I am making a first attempt at writing a simple C++ routine to print out R objects (this is a simple proof-of-concept as part of a larger package development). The relevant C++ routine is as follows: void Rwrite(SEXP fd, SEXP msg) { int *ofd = INTEGER(fd); const char * omsg = CHAR(asChar(msg)); printf("[%i] %s",*ofd,omsg); } And the corresponding interface in R is as

https://bugzilla.samba.org/show_bug.cgi?id=8666 Summary: --debug=all9 fail Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: chris at onthe.net.au QAContact: rsync-qa at

Since I use the Dante SOCKS library (instead of the NEC libraries), I decided to hack support for them into OpenSSH. Here is the results. Thanks, David $NetBSD$ --- configure.in.orig Wed Dec 29 08:37:01 1999 +++ configure.in Wed Dec 29 08:37:25 1999 @@ -334,6 +341,20 @@ AC_MSG_WARN([*** Disabling lastlog support *** ]) AC_DEFINE(DISABLE_LASTLOG) fi + +dnl Compile with dante SOCKS library

https://bugzilla.samba.org/show_bug.cgi?id=11338 Bug ID: 11338 Summary: Rsync Crash - Segmentation fault Product: rsync Version: 3.1.1 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

There's a bug reported in Debian about the tty being screwed up by wierd filenames, see http://bugs.debian.org/bug=242300 On the one hand, find will also do this. On the other hand, ls will replace such chars with a question mark. Upon inspection, it appears to be fairly simple to also do this in rsync (in the rwrite() function). Here's a patch. Opinions? Perhaps don't do it

Hello, Noticed this (bug?) while testing out rsync. For a little background, I need to push files real-time to some front-end servers, and I am thinking of switching from some custom shell scripts that do this job to rsync. I am thinking of running rsync as a daemon on the front-end servers, and doing an upload from the back-end server to push the data out as it comes in. So, here is the deal:

https://bugzilla.samba.org/show_bug.cgi?id=9502 Summary: Deamon deadlock at stop (SIGINT caught) Product: rsync Version: 3.0.7 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: jurij at ocslab.com

https://bugzilla.samba.org/show_bug.cgi?id=10776 Summary: SIGSEGV in utf8_internal_loop() Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mluscon at redhat.com

https://bugzilla.samba.org/show_bug.cgi?id=11683 Bug ID: 11683 Summary: hang on select when send many files Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: tom916 at

Attached is a very small patch that allows the ssh clients to use the socks5 library. It should work with socks4 but is untested. Tested on linux only configure --with-socks configure --with-socks5 Also included is a configure option to disable scp statistics --disable-scp-stats modified files openssh-2.9.9p2/acconfig.h openssh-2.9.9p2/channels.c openssh-2.9.9p2/configure.in

> Winton-- > > Excellent! Absolutely wonderful. > > I'm wondering which apps/encapsulators support 4A? This gets me > around > the DNS leakage problem quite nicely. > > Incidentally, we do need SOCKS5 support -- if for no other > reason, the > fact that there's *operating system* level support in OSX for SOCKS5 > redirection. So

Greetings and salutations, rsync users. I have a problem. I'm hoping that someone out there could perhaps provide a hand. I've been trying to transfer large amounts of data (lots of data, lots of files) via rsync over an encrypted TCP tunnel, but I seem to be continually getting hangs in the transfers -- things will go along for a bit, and then just come to a screetching halt. There