similar to: [patch] rsync over existing I/O connections (new feature)

Wayne, It's taken a little while for me to get more familiar with the code, but I think I've reached a good breakpoint in improving batch-mode. Let me highlight some of the changes in the attached patch: * --write-batch and --read-batch arguments are no longer passed from client to server. This fixes the current problem that causes the server threads to die when the client

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

Hi Folks -- I've recently had the need to add a piece of functionality to rsync that allows one to run 'rsync --daemon' (rsync in "rsync server" mode) over SSH. My main goal was to be able to use some of the features from rsyncd.conf(5) (notably modules) while still using SSH for authentication and network transport. Background: I wanted to have the capability of setting

Hello, Recently I noticed a disparity in the use of HOST::MODULE and rsync://HOST/MODULE syntax by rsync. HOST::MODULE can be used to both pull from and push to a remote rsyncd server, but rsync://HOST/MODULE can only be used to pull from a remote rsyncd server. The attached patch resolves this issue by also allowing a rsync:// URL to be used to push files to a remote rsyncd server. Testing:

Some of the debug messages that rsync outputs (when verbose >= 2) can occur on both sides of the connection. This makes it hard to know which program is saying what. Some debug messages deal with this by outputting a "[PID]" string at the start of the message. Unfortunately, the startup message that tells us which pid is which is only output when verbose >= 3, so there's a

Dear rsync people (particularly Wayne), I noticed that an rsync daemon counts on the client sending a --server option so that am_server gets set to 1. If the client doesn't supply this option, am_server remains 0 but the daemon runs start_server anyway. This is potentially dangerous and might lead to a security hole, although I haven't found one yet. I suggest that the daemon either

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 :

Any votes for/against? ----- Forwarded message from Rik Faith <faith@alephnull.com> ----- Date: Wed, 28 Nov 2001 12:55:29 -0500 From: Rik Faith <faith@alephnull.com> To: mbp@samba.org Subject: rsync patch X-Mailer: VM 6.96; XEmacs 21.1; Linux 2.4.16 (light) Here is a patch that adds rate information (e.g., kB/s) to the --progress display. I just noticed that 2.4.7pre4 is coming

Dear List, I'm confused when we will run into "if (motd && *motd)"? As I have found that Globals is set 0 during initialization, and I didn't find anywhere else assign the value. If so, should we remove this section? Or there might be some where I missed? Please correct me, if I'm wrong. Thanks in advance. clientserver.c #line 147~160 > if (!am_client) {

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

Wayne, Please consider the attached patch. This applies to the current CVS, and is independant of patches/local-batch.diff. As a matter of fact, I'm sure it would conflict heavily with local-batch.diff. This version of batch mode has a couple distinguishing features: Write-batch records (almost) the entire sender side of the conversation into one file. ("Almost" because it has

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/rsync/attachments/20040227/923b87ee/PGP.bin

--- Since the process executing the code inside the previous "if" (which doesn't close the log file) sets am_server = 1, I think the comment is backwards. pipe.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/pipe.c b/pipe.c index 12aa73d..101d4cb 100644 --- a/pipe.c +++ b/pipe.c @@ -150,7 +150,7 @@ pid_t local_child(int argc, char **argv, int *f_in, int

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

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

The attached patch makes two changes to the behavior of the -v option: 1) The initial "building file list ... done" and the last two lines with transfer statistics are moved to verbose level 2, which means that you have to specify -vv to see them. When I use -v, I only want to see which files are being updated. Perhaps the statistics could be controlled by a separate option,

It would be nice if there were a flag which would have rsync behave like a single -v but which would skip the two line summary info. I do a lot of cron-based transfers and I want to see what gets transferred if anything does, but I'd like it to be entirely silent otherwise. Here is a patch which makes a single -v behave this way. -vv causes it to include the extra info. diff -r -X

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

Here's the latest version of the batch mode cleanup patch. Index: batch.c =================================================================== RCS file: /cvsroot/rsync/batch.c,v retrieving revision 1.12 diff -u -r1.12 batch.c --- batch.c 24 Jan 2002 08:09:46 -0000 1.12 +++ batch.c 6 Feb 2002 19:47:57 -0000 @@ -8,55 +8,38 @@ #include "rsync.h" #include <time.h> -char

Dear rsync people, I have just started using rsync for backups. I have had a couple of issues. Note I'm trying to use rsync as user using ssh between two machines both running Debian GNU/Linux potato (2.2r3). The local machine is currently running 2.4.6-1 and the remote 2.3.2-1.2. 1) When I run rsync with the vv option, stuff scrolls of my screen faster than I can read it. I was wondering if