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