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

[Benjamin Watkins]

Benjamin Watkins wrote:

> Benjamin Watkins wrote:
>
>> 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.
>
>
>
> I can now confirm that this seems to happen whenever there is a long 
> file name error.  This appears to cause a corruption in the protocol 
> stream.
>
> -Ben : )
>
Testing with another set of machines further confirms the error with a 
twist.  This time no files are transferred before the program exits 
(still with an exit code of 3072).

The options I use when rsyncing files are:

(First two tests reported, workstations 1 and 2 to server 1)
-av --delete --delete-excluded --stats --ignore-errors --force 
--exclude-from=exclude.txt

(Most recent test, syncing server 1 to offsite server 2)
-av --delete --partial --stats --ignore-errors --force

These options are basically identical with the exception of the use of 
an excluded file in the first example.

Is anyone able to replicate these problems?  I will need to switch back 
to rsync 2.6.3 until this is resolved.  With this version I experienced 
occasional failures on large files, despite the fact that I am not using 
compression.  I did not bother to report this as version 2.6.4 was 
released shortly after I noticed the problem.  I was hoping that one of 
the following bug fixes would have happened to address this issue, 
though neither situation applies to me.  The symptoms are similar, however.

> - If an rsync daemon specified "dont compress = ..." for a file and 
> the client tried to specify --compress, the libz code was not handling 
> a compression level of 0 properly. This could cause a transfer failure 
> if the block-size for a file was large enough (e.g. rsync might have 
> exited with an error for large files).
>
> - Fixed a bug that would sometimes surface when using --compress and 
> sending a file with a block-size larger than 64K (either manually 
> specified, or computed due to the file being really large). Prior 
> versions of rsync would sometimes fail to decompress the data 
> properly, and thus the transferred file would fail its verification. 

I am not specifying compression either way for any of the clients or the 
daemons, so neither of these bugs should have been affecting me.

Hopefully someone else can confirm these problems (2.6.3, 2.6.4, or 
both), or possibly suggest a solution.

-Ben : )