Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
Hello, I suggest you to download new Long Path Tool software that simply allows you to work easily on Long Path files. Thank you. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
Benjamin Watkins wrote: I will let you know how the patch works for me. I am currently running it from Workstation 1 to Server 1. After more extensive testing with this patch, I can confirm that it does indeed resolve this issue for me under Cygwin. If Tev repackages his cwRsync package, I would recommend he applies this patch as this problem appears to be particularly noticeable with Cygwin. He should also use the most recent cygwin1.dll in order to resolve the exit code problem. I am assuming for simplicity's sake that Tevfik Karagülle is male, so my apologies if this is incorrect. -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
Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
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 : ) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
On Fri, Apr 01, 2005 at 03:54:38PM -0500, Benjamin Watkins wrote: multiplexing overflow 1:296 [sender] This indicates that there is an error message arriving (1) that has a length of 296 bytes, but this is too long for the line buffer in readfd_unbuffered(). I changed the length of this buffer from 1024 bytes to MAXPATHLEN+1 because it was too short for receiving info/error messages for really long file names (since a normal system has a MAXPATHLEN that is closer to 4 KB). (Hmm, is MAXPATHLEN really supposed to be that short under Cygwin? Surprising...) Anyway, the simple solution is to just make the line buffer larger. I'll attach a patch. In addition, the client actually exits with a status code of 3072, not 12 as indicated by the standard error message. That sounds like a problem with your shell or the Cygwin environment because rsync exits with the right error code under Linux. ..wayne.. --- io.c4 Apr 2005 00:48:39 - 1.167 +++ io.c4 Apr 2005 01:07:10 - @@ -706,7 +706,11 @@ static int readfd_unbuffered(int fd, cha static size_t remaining; static size_t iobuf_in_ndx; int tag, ret = 0; - char line[MAXPATHLEN+1]; +#if MAXPATHLEN 4096 + char line[4096+1024]; +#else + char line[MAXPATHLEN+1024]; +#endif if (!iobuf_in || fd != sock_f_in) return read_timeout(fd, buf, len); -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
Wayne Davison wrote: On Fri, Apr 01, 2005 at 03:54:38PM -0500, Benjamin Watkins wrote: multiplexing overflow 1:296 [sender] This indicates that there is an error message arriving (1) that has a length of 296 bytes, but this is too long for the line buffer in readfd_unbuffered(). I changed the length of this buffer from 1024 bytes to MAXPATHLEN+1 because it was too short for receiving info/error messages for really long file names (since a normal system has a MAXPATHLEN that is closer to 4 KB). (Hmm, is MAXPATHLEN really supposed to be that short under Cygwin? Surprising...) The maximum length under truly does appear to be this short, at least when I have not manually set it to be anything. Anyway, the simple solution is to just make the line buffer larger. I'll attach a patch. In addition, the client actually exits with a status code of 3072, not 12 as indicated by the standard error message. That sounds like a problem with your shell or the Cygwin environment because rsync exits with the right error code under Linux. Odd, since I've been using the pre-compiled binaries from cwRsync for some time now. This is the first version that returns this error code. I do not have Cygwin installed, and I simply use cmd.exe as my shell. The only Cygwin environment variable I set is CYGWIN=nontsec, which does not appear to affect the maximum path length. Perhaps I could try using an older cygwin1.dll, though this may cause other problems. I think it is time I finally install cygwin myself and compile these things on my own. Ok, done. I am now using my own compiled and patched version of rsync. It is surprisingly much larger than the one from the cwRsync package. I will let you know how the patch works for me. I am currently running it from Workstation 1 to Server 1. Thanks for your quick response. -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
Re: Rsync 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
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 : ) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
