If I execute the following command: rsync -vrptgz --rsh="ssh $BCPSERVER rsync rsyncd --daemon -- config=$RSYNCDCONFIGFILE --port=$RSYNCDPORT" --rsync-path=$RSYNCPATH $RSYNCSOURCE $LOGNAME@$BCPSERVER::$RSYNCDESTINATIONMODULE and I have a symbolic link in the directory represented by $RSYNCSOURCE then I get the following output: building file list ... 5 files to consider overflow: linkname_len=1862797370 ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at util.c(126) rsync: connection unexpectedly closed (4 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(359) If I add the -l option to the command then rsync seems to complete fine however the symbolic links that have the following pattern symlink -> /foo/bar get rsynced to symlink -> foo/bar. I looked at the source and I have found the code that generated the errors that I see. below is the code section from flist.c: #if SUPPORT_LINKS if (preserve_links && S_ISLNK(mode)) { linkname_len = read_int(f) + 1; /* count the '\0' */ if (linkname_len <= 0 || linkname_len > MAXPATHLEN) { rprintf(FERROR, "overflow: linkname_len=%d\n", linkname_len - 1); overflow("receive_file_entry"); } } else #endif I cannot figure out why we are actually executing this section of code if our preserve_links && S_ISLNK variables are not set to 1, which I do not see that they are given the rsync arguments that we are using.
*** Bug 2785 has been marked as a duplicate of this bug. ***
This sounds like the bytes being transfer are being corrupted between the sender and the receiver, possibly because your remote-shell transport is not 8-bit clean. You can test this using the "savetransfer" program in the support dir of a modern rsync release. Just chdir into the support dir, type make, and then read the savetransfer.c file's opening comments for how to make a copy of the data that is being sent or received (one copy on the sender, and one on the receiver) and then diff it for errors. Your --rsh options are also strange: you're using a --port option that has no effect, for instance (because you'r using a remote shell to talk directly to a freshly-spawned daemon process over stdin/stdout). The specifying of rsync options is more appropriately done in the --rsync-path option rather than in the --rsh option. For instance, rsync is appending the --server --daemon options onto the rsync command, so the command you list is running this (this is a single command): ssh BCPSERVER rsync rsyncd --daemon --config=FILE --port=PORT BCPSERVER /PATH/rsync --server --daemon If you changed the --rsh option to be just "ssh" and changed the --rsync-path option to be "$RSYNCPATH --config=$RSYNCDCONFIGFILE", it would run something more like this: ssh BCPSERVER /PATH/rsync --config=FILE --server --daemon
I get the following errors when not using the -rsh= ssh option: ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at util.c(126) rsync: connection unexpectedly closed (4 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(359) It appears to have the same problem regardless of the transport layer.
disregard my last comment, the code does act as you suggest when not using the ssh as the transport layer. Are there any known work arounds for this behavior?
I made additional mods to the way the script uses ssh as the protocl and it worked thanks for the help.