Benjamin Watkins wrote:
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).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 : )
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 : )
-- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
