Red Hat Bugzilla – Bug 58874
New rsync package corrupts files during transfer.
Last modified: 2014-03-16 22:25:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
After upgrading to the new rsync package using rsync-2.4.6-8.i386.rpm, strange
things started happening. We run the following command on our machines daily:
rsync -a -H -v /local/rh/7.2/install/files/ /
/local/rh is mounted over NFS from a RedHat Linux 6.2 server.
After installing the updated rsync package, it started printing the following
error after a copying certain file:
[root@zag root]# rsync -a -H -v /local/rh/7.2/install/files/ /
building file list ... done
Warning: unexpected read size of 0 in map_ptr
Warning: unexpected read size of 0 in map_ptr
wrote 15643 bytes read 438 bytes 32162.00 bytes/sec
total size is 1175178 speedup is 73.08
After running this, sendmail refused to start with an error:
[root@zag root]# /etc/init.d/sendmail start
Starting sendmail: 554 5.0.0 /etc/sendmail.cf: line 412: readcf: unknown option
name DaemME-encapsulated error messages?
Warning: OperatorChars is being redefined.
It should only be set before ruleset definitions.
I looked at the new /etc/sendmail.cf and it is not identical to the one from
where rsync copied it. Running diff reports:
[root@zag root]# diff /etc/sendmail.cf /local/rh/7.2/install/files/etc/sendmail.cf
Binary files /etc/sendmail.cf and /local/rh/7.2/install/files/etc/sendmail.cf differ
Running diff -a shows shows -lots- of lines changed.
The files contain a different line count:
[root@zag root]# wc -l /etc/sendmail.cf /local/rh/7.2/install/files/etc/sendmail.cf
So, obviously, the new rsync corrupts our sendmail.cf and maybe
other files. I can provide more info if needed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Put the default RedHat 7.2 sendmail.cf file on a NFS mounted file
system, preferably from a vanilla RedHat 6.2 server, and make a simple
modification to it.
2.Use rsync to copy it to local disk -overwriting- the old sendmail.cf file (if
the old sendmail.cf is not present, the problem will not reproduce)
3. Compare the files.
Actual Results: The new sendmail.cf is corrupted
Expected Results: sendmail.cf should have been updated without causing breakage
Do you have a reliable case that reproduces this?
This one's tricky to pin down for me. Taking the rsync-2.4.6-unsigned.dif patch
out seems to fix it though. I'm attaching my test script which shows the
problem on my box.
Created attachment 43657 [details]
test script for rsync corruption bug
Hm, I can reproduce it with this test on the errata binary, but not on one I
Arg! I didn't think of trying that. It works for me if I simply rebuild the
srpm as well.
Looks like a bad build somehow. Not sure if it's important or not, but
grep 64 <strings of bad rsync>
grep 64 < strings of good rsync>
shows that the bad one is missing the 64 bit io functions. (fopen64, glob64,
Also, I don't see GLIBC_2.2 in the strings output of the bad rsync.
OK, I think I've figured out the build problem; please try:
Works great for me - good job tracking this down over the weekend.
Can't wait to see the src rpm to see what fixed it.
Nothing. :( Solely a problem with the build machine.
I just downloaded the new rsync package from
and it does work fine on my machine indeed.
Thanks for your hard work!
I'm getting this error using the rsync just released as a security update. The
rsync in the RedHat 7.2 distribution did not have this problem. How did you
manage to release a broken RPM as a security update?
Sorry. I see the the errata was published before this bug report. I assume
there's going to be an errata errata :-)
*** Bug 59013 has been marked as a duplicate of this bug. ***
*** Bug 58878 has been marked as a duplicate of this bug. ***
*** Bug 59026 has been marked as a duplicate of this bug. ***
What's the real problem, then? Is the Raw Hide package actually broken, or is
it purely the older version when used as the server side?
The problem is in the patch for the security problem. The fact that -9 works is
because building with LFS support manages to mask the problem on x86.
Well, the http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm package does
indeed work for me.
Does either -8 or -9 actually fix the security problem? If they do,
then I'll run -9 until the problem with the security patch can be
corrected and a new errata released; otherwise, I'll just drop back to
-5 (what shipped with RH7.2)...
Both packages fix the security problem (after all, that's why it was an errata
in the first place.)
I got segfaults on redhat 7.2 with rsync
when rsync was trying to update a remote file
cured that problem.
If anyone's interested, the 2.4.6-8 is broken for me (ie. it corrupts files),
but http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm fixes the problem.
Surely if an updated update can't be released immediately, the broken rsync
should be removed or a notice about it released? In my case at least, a bug
that randomly corrupts files is way worse than a security hole that can't be
exploited (since I don't provide rsync to the world).
I would like to thank you for fixing the rsync problem, and curse you for the
fact that my mozilla bookmarks file was corrupted beyond recognition by rsync.
This problem still exists in rsync 2.4.6-10 under RedHat 7.0. The transferred
files get corrupted. My command line is:
$ rsync -a -e ssh --rsync-path=/home/smith/.bin/rsync --cvs-exclude -v
which transfers a bunch of files named *RANKS to my local machine.
Forgot to mention in my previous comment: the remote rsync is 2.5.2 under
$ ssh remotesite uname -a
SunOS uw 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-1
$ ssh remotesite rsync --version
rsync version 2.5.2 protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
Capabilities: 32-bit files, socketpairs, hard links, symlinks, batchfiles, no
32-bit system inums, 64-bit internal inums
Take the rsync-2.4.6-10 package, and extract the -moresignage patch. You most
likely need to apply that to the rsync on your Solaris box....