rsync - Dec 2004 - trouble with chmod on certain symlinks

hello-

i am using rsync via ssh to maintain a copy of a few directories on a 
remote server, and am getting an error when rsync tries to chmod a 
certain file following it's transfer.  there are a couple of cases in 
which this occurring - below is one example.

local machine is debian testing - rsync version 2.6.3  protocol version 
28
remote machine is macos x 10.3.7 - rsync version 2.6.2  protocol 
version 28

there is another file of this type (symlink to ssl cert) that is 
transferred as part of another rsync without trouble.  i've compared 
permissions, ownership, etc between the 2, and cannot figure out why 
one works but the other doesn't.  if i do the command with -L instead 
of -l, it works, but of course that balloons the remote directory in 
size.

i've verified the file exists - in fact because rsync put it there:

ion:/ root# l 
/Users/luna/Documents/backups/groundnoise/etc/courier/imapd.pem
lrwxrwxrwx  1 daemon  daemon  53B 27 Dec 22:06 
/Users/luna/Documents/backups/groundnoise/etc/courier/imapd.pem -> 
/etc/ssl/localcerts/mail.groundnoise.net-key_cert.pem
ion:/ root#

root@under:/etc/courier# /usr/bin/rsync -e ssh -vvvzlptogrR --delete 
/etc/courier ion:/Users/luna/Documents/backups/groundnoise/
opening connection using ssh ion rsync --server -vvvlogtprRz --delete . 
/Users/luna/Documents/backups/groundnoise/
building file list ...
[sender] make_file(/etc,*,2)
[sender] expand file_list to 131072 bytes, did move
[sender] make_file(/etc/courier,*,2)
[sender] make_file(/etc/courier/imapd,*,2)
[sender] make_file(/etc/courier/imapd-ssl,*,2)
[sender] make_file(/etc/courier/imapd.pem,*,2)
[sender] make_file(/etc/courier/authdaemonrc,*,2)
[sender] popping per-dir .cvsignore exclude list
done
send_file_list done
send_files starting
server_recv(2) starting pid=3885
recv_file_name(/etc)
recv_file_name(/etc/courier)
recv_file_name(/etc/courier/imapd)
recv_file_name(/etc/courier/imapd-ssl)
recv_file_name(/etc/courier/imapd.pem)
recv_file_name(/etc/courier/authdaemonrc)
received 6 names
recv_file_list done
get_local_name count=6 /Users/luna/Documents/backups/groundnoise/
[receiver] make_file(etc/courier,*,2)
[receiver] expand file_list to 131072 bytes, did move
[receiver] make_file(etc/courier/authdaemonrc,*,2)
[receiver] make_file(etc/courier/imapd,*,2)
[receiver] make_file(etc/courier/imapd-ssl,*,2)
[receiver] make_file(etc/courier/imapd.pem,*,2)
[receiver] clearing per-dir .cvsignore exclude list
send_file_list done
deleting in etc/courier
generator starting pid=3885 count=6
delta transmission enabled
recv_generator(etc,0)
recv_generator(etc/courier,1)
recv_generator(etc/courier/authdaemonrc,2)
etc/courier/authdaemonrc is uptodate
recv_generator(etc/courier/imapd,3)
etc/courier/imapd is uptodate
recv_generator(etc/courier/imapd-ssl,4)
etc/courier/imapd-ssl is uptodate
recv_generator(etc/courier/imapd.pem,5)
set uid of etc/courier/imapd.pem from 1 to 0
set gid of etc/courier/imapd.pem from 1 to 0
chown
"/Users/luna/Documents/backups/groundnoise/etc/courier/imapd.pem"
failed: No such file or directory     <----error here
generate_files phase=1
send_files phase=1
recv_files(6) starting
recv_files phase=1
generate_files phase=2
send files finished
total: matches=0  tag_hits=0  false_alarms=0 data=0
recv_generator(etc,0)
recv_generator(etc/courier,1)
generate_files finished
recv_files finished

sent 251 bytes  received 20 bytes  542.00 bytes/sec
total size is 21470  speedup is 79.23
rsync error: some files could not be transferred (code 23) at 
main.c(702)
_exit_cleanup(code=0, file=main.c, line=702): about to call exit(23)

any insight is greatly appreciated!

-ben

On Mon, Dec 27, 2004 at 10:34:13PM -0500, btb wrote:
> chown
"/Users/luna/Documents/backups/groundnoise/etc/courier/imapd.pem"
> failed: No such file or directory     <----error here
It may be that OS X is transferring the chown() call from the symlink to
the referent.  Try to chown it manually (either use the chown command,
or compile a program that does nothing but chown a symlink) and see if
that works.  If not, perhaps the OS X version of rsync should be tweaked
to avoid trying to chown() a symlink.

..wayne..

I and a few others have seen similar problems.  It happens (as I understand)
because Darwin (the BSD underlying Mac OS X) follows symlinks with chown
attempts--try chown'ing a symlink from the command line to see this--which
is...unintuitive.  So when given the -o or -g (or -a) options, rsync can
unintentionally end up following links and resetting the permissions on the
target, not the symlink.

Jonathan Paisley at Glasgow (UK) Computing Science has used the patch below
in the rsyncX.c source (but should be same for rsync?), preventing it from
following symlinks in this situation; I have not tried this myself.  Hope
this helps.

Ben
-----

diff -u -r1.1.1.6 rsync.c
--- rsync.c     3 Jan 2004 11:22:00 -0000       1.1.1.6
+++ rsync.c     21 Dec 2004 12:04:56 -0000
@@ -260,7 +260,7 @@
                     change to groups that the user is a member of */
                 change_gid = is_in_group(file->gid);
         }
-       if (change_uid || change_gid) {
+       if (!S_ISLNK(st->st_mode) && (change_uid || change_gid)) {
                 if (do_lchown(fname,
                               change_uid?file->uid:st->st_uid,
                               change_gid?file->gid:st->st_gid) != 0) {


On 12/28/04 6:00 AM, btb <btb@bitrate.net> wrote:
> i am using rsync via ssh to maintain a copy of a few directories on a
> remote server, and am getting an error when rsync tries to chmod a
> certain file following it's transfer.  there are a couple of cases in
> which this occurring - below is one example.