Hi, I use rsync in the following way to update some remote files over a low bandwidth line: rsync -v -r -z -t -p <local dir> <user>@<host>:<dir on host> After updating from rsync 2.5.2 to 2.5.4 I noticed that modified files are always copied completely. The problem seems to be related to the new (in 2.5.3) option -no-whole-file. The global variable whole_file is initialized to -1 in options.c. In server_options() (options.c) it is set to zero if the original value has not been changed. A value of zero on whole_file is not transmitted to the remote rsync however. So the remote rsync has -1 instead of zero on its whole_file variable. To fix the problem I applied the following patch that forwards --no-whole-file to the remote side if whole_file has a value of zero: --- options.c.O Fri Mar 15 10:25:42 2002 +++ options.c Fri Mar 15 10:27:24 2002 @@ -758,6 +758,8 @@ args[ac++] = compare_dest; } + if (!whole_file) + args[ac++] = "--no-whole-file"; *argc = ac; } Best regards, Frank Schulz -------------- next part -------------- HTML attachment scrubbed and removed
On 15 Mar 2002, "Schulz, Frank" <FSchulz@mbisoftware.de> wrote:> Hi, > > I use rsync in the following way to update some remote files over a low > bandwidth line: > rsync -v -r -z -t -p <local dir> <user>@<host>:<dir on host> > After updating from rsync 2.5.2 to 2.5.4 I noticed that modified files are > always copied completely. The problem seems to be related to the new (in > 2.5.3) option -no-whole-file. The global variable whole_file is initialized > to -1 in options.c. In server_options() (options.c) it is set to zero if the > original value has not been changed. A value of zero on whole_file is not > transmitted to the remote rsync however. > So the remote rsync has -1 instead of zero on its whole_file variable. To > fix the problem I applied the following patch that forwards --no-whole-file > to the remote side if whole_file has a value of zero:Thanks. I think that particular fix would break interoperability with servers that did not have --no-whole-file, but I've put in something that I think is equivalent. Regards, -- Martin
I have an Empeg car MP3 player (http://www.empeg.com) that is running an embedded version of Linux on a StrongARM CPU. When using rsync 2.5.5 on Linux/ARM and rsync 2.5.5 on Linux/x86 to transfer mp3 files, it appears file are always transmitted as a whole, even if only the timestamp differs. Files are not transmitted if both size and timestamp are equal. Files are not transmitted if timestamps differ only, and --checksum is used. Files are always transmitted, if files at each end differ only slightly (ie changed id3 tags at the end of the file). Adding --no-whole-file makes no difference. I compiled the 2.5.5 version myself, using a linux/x86 hosted cross-compiler. Yesterday's CVS snapshot does not fix the problem. A binary version 2.4.6 I found on the web has the same problem. A binary version 2.3.2 built by debian does not have the problem. Unfortunately, this version has other problems I will not bother this forum with. Using -vvvv, I can see checksums are being calculated, but no matches are appearant. Where do I start debugging this problem? Should I be looking for gcc bugs, or alignment problems or anything else? Thanks, Pim