similar to: Prevent infinite recursion in rwrite()

(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

Rsync 2.5.5; transfer via ssh; sparc-sun-solaris2.5 (Ultra 1); gcc 2.8.1. Every time rsync on this box causes boundary violation. I attached two strange examples. I have a few rsync's corefiles (100MB and above) and I can examine them. I will be grateful for any help. -Mirek <-------------------------------------------------------------------------> received 966761 names done

-----BEGIN PGP SIGNED MESSAGE----- With rsync --server, sometimes when the remote side control-C's a transfer, rsync will immediately start consuming all available RAM. gdb shows that its recursing while trying to report the failed write: #0 0x420503ac in vfprintf () from /lib/i686/libc.so.6 #1 0x42072f74 in vsnprintf () from /lib/i686/libc.so.6 #2 0x08052ca4 in rprintf

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:

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

seems the behavior of rsync has changed when dealing with output and using both -v and -q at the same time ... for example: $ mkdir test1 $ touch test1/foo $ rsync-2.6.0 -avq test1 test2 $ rm -r test2 $ rsync-2.6.8 -avq test1 test2 test1/ test1/fo $ rm -r test2 $ rsync-cvs -avq test1 test2 building file list ... test1/ test1/fo $ rm -r test2 the new output in 2.6.8 comes from the calls to

Hi All, I am trying to see the rsync source code. I could see that there are main three processes: I realize that Server or Client becomes Sender or Receiver based on arguments provided. 1. Daemon start_daemon : clientserver.c 2. Server if(sender) { call recv_filter_list : exclude.c call send_file_list : flist.c call send_files :

-----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.

(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

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

Hi guys: First post for me on this list. THE PROBLEM =========== I have several linux servers (ranging from Redhat 7.3 to FC3) that use Rsync (version 2.6.8 and 2.6.7, read on for reasons) to backup their data. A typical rsync backup script looks like this: ------------------------------------------------------------------------------------------ #!/bin/sh RSYNC_PASSWORD=<PASSWORD> rsync

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

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

I use rsync to mirror several servers. I run RH7.3 My rsyncd.conf file is: motd file = /etc/rsync.d/rsync.motd log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock hosts allow = 10.1.2.200 10.1.2.201 hosts deny = 0.0.0.0/0.0.0.0 use chroot = yes max connections = 3 #syslog facility = [website] path = /var/www/website comment = Connex Live WWW

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

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

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

https://bugzilla.samba.org/show_bug.cgi?id=4139 Summary: Generator process (running as daemon) hangs after kill SIGINT. Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

Using rsync 2.6.0 with --verbose and doing a pull. >?receiving file list ... readlink "{FILENAME}" failed: >?No such file or directory >?done >?IO error encountered - skipping file deletion The file was a temporary file that was being deleted just as the rsync was run. So while the file list was being built, it was there when the directory was read but had vanished by the

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: