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.