2.5.7 vs 2.6.1 interoperability bug
danno at internet2.edu
Wed Apr 28 21:33:24 GMT 2004
Hi all -
I've got two red hat linux 7.3 systems.
On each i have the redhat-provided 2.5.7 in the standard location,
and a locally built copy of 2.6.1 in /usr/local/pkg.
I'm implementing a remote-backup-to-disk setup.
blakey is the "client" (source of rsync), verve is the "server" (dest
When i take care to match rsync binary versions (2.5.7 on each side,
or 2.6.1 on each side) things seem to work fine.
However, when i run 2.5.7 on the client and 2.6.1 on the server,
i get bad corruption.
[root at blakey bin]# which rsync
[root at blakey bin]# rsync --version
rsync version 2.5.7 protocol version 26
line split for readability...
[root at blakey bin]# rsync -aRx -e ssh
--exclude-from=/tmp/excludes --numeric-ids --delete --delete-after
/ root at verve:/home/blakey-ext3/plain9
[root at blakey bin]# ls -l /bin/vi
-rwxr-xr-x 1 root root 434856 Jan 15 2003 /bin/vi
[root at verve bin]# ls -l /home/blakey-ext3/plain9/bin/vi
-rwxr-xr-x 1 root root 4096 Jan 15 2003 /home/blakey-ext3/plain9/bin/vi
I first noticed this when I had built 2.6.1 statically linked, but the
problem occurs with a dynamically-linked version as well.
The --link-dest option "doesn't work" across these versions either - when
i specify it i don't get hardlinks for common files. Maybe it is
checking the proper contents vs. the wrong file on the --link-dest area,
which fails, and then the corruption happens later.
Some of the files I am able to identify as mis-named. For instance,
"/bin/sed" on the target contains the contents of "/bin/vi" from the
source. On the other hand I'm not able to figure out where the contents
of /bin/vi come from - and the 4096 size is quite suspicious.
I'm happy to provide other debugging if that helps.
dan pritts danno at internet2.edu
systems administrator 734/352-4953 office
internet2 734/834-7224 mobile
More information about the rsync