rsync - Sep 2003 - bug (filelist) for platforms solaris and darwin (macosx) and *not* linuxi386

I have found a nasty bug when a file, which is in some of many sources, 
shall be copied to a target.

The linux-Version works well but rsync 2.5.{2|5|6} under solaris9 (gcc 
2.95.3) and darwin (gcc 3.1) do not. The decision which file (out of which 
src) shall be copied depends on the number of src dirs given on the command 
line.

This bug bytes us very hard, because we decided to rely on rsync to build 
local directories by "overlaying" different directories from a server
and
need to be sure to have a consistent semantics in what version of the file 
appears in the local directory.

I stripped our sitation down to a (yet fairly complex) test archive, so you 
can reproduce the situation.

Here is the script, which is also in the archive:

#!/bin/bash
rsyncpath=rsync
$rsyncpath -av --delete  dir1/ dir2/ merged12
$rsyncpath -av --delete  dir1/ dir2/ dir3/ merged123
# as dir3 only consists of an empty dir "subdir" we expect
# that merged12 and merged123 have identical files in them
# but merged*/subdir/s0/LOOKATTHIS differ as they come from different 
sources:
diff -c merged*/subdir/s0/LOOKATTHIS
# this has been reproduced for rsync Version 2.5.2, 2.5.5 and 2.5.6 under
# solaris9 (gcc 2.95.3) and darwin (gcc 3.1)
# this bug *cannot* be reproduced under linuxi386 (gcc 2.95.4)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsynctest.tgz
Type: application/x-gzip
Size: 888 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20030928/93022cf3/rsynctest.bin

Hello,

I wrote this report one and a half weeks ago. There is a bug in the 
"flist"-module, which can consistently reproduced on at most two 
Unix-Platforms: Solaris 9 and MacOS X.

Can anybody help me with the email-address of the developer of the 
flist-module, so I can contact him/her directly?

Thanks,
Dirk.
-- 
Dr. Dirk Pape (Leiter des Rechnerbetriebs und IT-Verantwortlicher)
Fachbereich Mathematik und Informatik der FU Berlin
Takustr. 9, 14195 Berlin
Tel. +49 (30) 838 75143, Fax. +49 (30) 838 75190

--Am Sonntag, 28. September 2003 13:19 Uhr +0200 schrieb Dirk Pape 
<pape@inf.fu-berlin.de>:
> I have found a nasty bug when a file, which is in some of many sources,
> shall be copied to a target.
>
> The linux-Version works well but rsync 2.5.{2|5|6} under solaris9 (gcc
> 2.95.3) and darwin (gcc 3.1) do not. The decision which file (out of
> which src) shall be copied depends on the number of src dirs given on the
> command line.
>
> This bug bytes us very hard, because we decided to rely on rsync to build
> local directories by "overlaying" different directories from a
server and
> need to be sure to have a consistent semantics in what version of the
> file appears in the local directory.
>
> I stripped our sitation down to a (yet fairly complex) test archive, so
> you can reproduce the situation.
>
> Here is the script, which is also in the archive:
>
># !/bin/bash
> rsyncpath=rsync
> $rsyncpath -av --delete  dir1/ dir2/ merged12
> $rsyncpath -av --delete  dir1/ dir2/ dir3/ merged123
># as dir3 only consists of an empty dir "subdir" we expect
># that merged12 and merged123 have identical files in them
># but merged*/subdir/s0/LOOKATTHIS differ as they come from different
># sources:
> diff -c merged*/subdir/s0/LOOKATTHIS
># this has been reproduced for rsync Version 2.5.2, 2.5.5 and 2.5.6 under
># solaris9 (gcc 2.95.3) and darwin (gcc 3.1)
># this bug *cannot* be reproduced under linuxi386 (gcc 2.95.4)