Rsync 2.6.4 Multiplexing Overflows when File Name Too
ben-list at constant-technologies.com
Sun Apr 3 15:29:22 GMT 2005
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
> -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
(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 : )
More information about the rsync