Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)

[Benjamin Watkins]

I installed the newly released version of cwRsync today on a few Windows 
machines and have noticed a new problem that I have not seen mentioned 
anywhere.

When syncing to an NT machine used for backups, my rsync client exited 
at the end of the transfer with the following message to standard error:

multiplexing overflow 1:296 [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(777)

The server daemon logs the following error regarding a file with a name 
that is too long before this error:

2005/04/01 13:01:43 [365] rsync: mkstemp "(very long file name 
removed).000679" (in backup) failed: File name too long (91)
2005/04/01 13:01:43 [365] (various other files being backed up, all with 
same timestamp)
2005/04/01 13:01:43 [365] rsync: writefd_unbuffered failed to write 12 
bytes: phase "unknown" [generator]: Connection reset by peer (104)
2005/04/01 13:01:43 [365] rsync error: error in rsync protocol data 
stream (code 12) at io.c(1080)

There is no mention of this long file name error in the standard error 
or standard out of the client rsync process.  Incidentally, this is an 
error I have seen for a long time with previous versions of rsync, but 
it was always visible in the standard error from the client.  Although 
the transfer appears to have completed (i.e. everything has syncs up as 
expected), the client then exists without printing the statistics it 
normally does (it is invoked with --stats).  In addition, the client 
actually exits with a status code of 3072, not 12 as indicated by the 
standard error message.  The binary-aware reader may notice that this is 
actually 12 * 256.

Interestingly, when I manually copied the offending long-named file to 
the server and reran the rsync session, the program terminated 
successfully with the normal "some files could not be transferred" 
status I am used to.  This was also multiplied by 256 in the client 
rsync process exit code to become 5888 instead of 23.  I'm sure the exit 
code anomaly is not related to the multiplexing error I am experiencing, 
which is the main problem I am having.

So far this observation has been made on one out of one clients that I 
have tested.  I was able to repeat this error several times on this 
machine before I discovered the message in the server log pointing me to 
the long file name problem.  I am running a test from another client to 
duplicate this problem, but this process will not finish for at least 
another half hour.  I will report back when I know if this happens on 
that system as well.

Otherwise, I am a very happy rsync user of many years.  Thanks for a 
great example of what FOSS can accomplish.

-Ben : )