Bug 58874 - New rsync package corrupts files during transfer.
New rsync package corrupts files during transfer.
Product: Red Hat Linux
Classification: Retired
Component: rsync (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Aaron Brown
: 58878 59013 59026 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-01-26 02:30 EST by akopps
Modified: 2014-03-16 22:25 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-01 11:54:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test script for rsync corruption bug (266 bytes, patch)
2002-01-27 03:00 EST, msterret
no flags Details | Diff

  None (edit)
Description akopps 2002-01-26 02:30:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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
   1964 /etc/sendmail.cf
   1490 /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):

How reproducible:

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

Additional info:
Comment 1 Bill Nottingham 2002-01-27 00:48:20 EST
Do you have a reliable case that reproduces this?
Comment 2 msterret 2002-01-27 02:59:01 EST
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.
Comment 3 msterret 2002-01-27 03:00:15 EST
Created attachment 43657 [details]
test script for rsync corruption bug
Comment 4 Bill Nottingham 2002-01-27 10:01:18 EST
Hm, I can reproduce it with this test on the errata binary, but not on one I
build. Uh-oh.
Comment 5 msterret 2002-01-27 10:15:14 EST
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,
lseek64, readdir64)

Also, I don't see GLIBC_2.2 in the strings output of the bad rsync.
Comment 6 Bill Nottingham 2002-01-27 12:13:51 EST
OK, I think I've figured out the build problem; please try:

Comment 7 msterret 2002-01-27 14:12:18 EST
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.
Comment 8 Bill Nottingham 2002-01-27 14:26:58 EST
Nothing. :( Solely a problem with the build machine.
Comment 9 akopps 2002-01-28 15:22:18 EST
I just downloaded the new rsync package from
and it does work fine on my machine indeed.
Thanks for your hard work!


Comment 10 Jeremy Sanders 2002-01-29 07:34:19 EST
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?

Comment 11 Jeremy Sanders 2002-01-29 07:47:00 EST
Sorry. I see the the errata was published before this bug report. I assume
there's going to be an errata errata :-)
Comment 12 Bill Nottingham 2002-01-29 10:41:54 EST
*** Bug 59013 has been marked as a duplicate of this bug. ***
Comment 13 Bill Nottingham 2002-01-29 10:42:10 EST
*** Bug 58878 has been marked as a duplicate of this bug. ***
Comment 14 Bill Nottingham 2002-01-29 11:47:37 EST
*** Bug 59026 has been marked as a duplicate of this bug. ***
Comment 15 Bill Crawford 2002-01-29 12:19:47 EST
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?
Comment 16 Bill Nottingham 2002-01-29 12:29:09 EST
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.
Comment 17 James Ralston 2002-01-29 16:26:21 EST
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)...
Comment 18 Bill Nottingham 2002-01-29 16:33:18 EST
Both packages fix the security problem (after all, that's why it was an errata
in the first place.)
Comment 19 T 2002-01-29 17:07:00 EST
I got segfaults on redhat 7.2 with rsync 
when rsync was trying to update a remote file

cured that problem.

Comment 20 Geoffrey D. Bennett 2002-01-30 03:25:21 EST
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).
Comment 21 Paul Johnson 2002-01-30 04:59:08 EST
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.
Comment 22 Need Real Name 2002-03-01 11:51:12 EST
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 
remotesite:mydir/\*RANKS .

which transfers a bunch of files named *RANKS to my local machine.
Comment 23 Need Real Name 2002-03-01 11:54:06 EST
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
Comment 24 Bill Nottingham 2002-03-01 12:25:23 EST
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....

Note You need to log in before you can comment on or make changes to this bug.