Unexpected rsync behavior with --relative and symlink destinations

Christopher Schanzle schanzle at nist.gov
Wed Dec 4 20:01:01 EST 2002


Hello, all.  Sorry if this topic has been hashed out before -- I didn't 
see it searching the archives of this list.

I want to mirror a local system's /apps and /usr/local directories (both 
are real directories, not symlinks) to a remote system where /apps and 
/usr/local are symlinks to /local/apps and /local/usrlocal, 
respectively.  The target directories exist on the remote system.  I 
would have thought the following would do it:

rsync -n -e ssh -av --relative /apps /usr/local /home dest:

shows me the expected files to update.  Removing the -n results in all 
the files being copied, with the first file being listed as "apps/" 
followed by filenames that shouldn't need to be copied and were not 
listed with the above "rsync -n ..."  On the destination side, /apps is 
no longer a symlink and is replaced with a real directory.  All files 
are resent/copied to this new directory.  I tried these too:

rsync -av -e ssh --relative /apps/. /usr/local/.    dest:
rsync -av -e ssh --relative /apps/* /usr/local/*    dest:
rsync -av -e ssh --relative /apps/*/ /usr/local/*/  dest:

In each case, the symlink on dest:/apps was replaced with a directory.

I realize I can work around this via separate commands, which works fine:

rsync -av -e ssh /apps/       dest:/apps
rsync -av -e ssh /usr/local/  dest:/usr/local

Is this the expected behavior of --relative?  If so, could the 
documentation be clarified?

More specifically, if dest:/apps/apache-1.3.26/ exists and is up to date 
(again, where dest:/apps is a symlink):

# rsync -n -av -e ssh --relative /apps/apache-1.3.26/   dest:
building file list ... done
wrote 177990 bytes  read 20 bytes  39557.78 bytes/sec
total size is 256768589  speedup is 1442.44
# rsync -av -e ssh --relative /apps/apache-1.3.26/   dest:
building file list ... done
apps/
apps/apache-1.3.26/
/apps/apache-1.3.26/Makefile
/apps/apache-1.3.26/Makefile.tmpl
/apps/apache-1.3.26/apache_1.3.26.tar
^Crsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)

I wouldn't expect (1) rsync would change touch dest:/apps at all, (2) 
differ so drastically in the output of "-n" and not, and (3) to replace 
dest:/apps symlink with a new directory.

Both hosts are SPARC Solaris 2.8 systems using UFS filesystems.

TIA,
Chris





More information about the rsync mailing list