When a symlink has contents in the file list (which happens for implied symlinks from --relative), rsync's dry-run output can be inaccurate because it naively tries to follow the symlink when processing the contents, even though it has not actually created the symlink. I reproduced this as follows in an empty directory: $ mkdir -p src/a dest/a $ ln -s a src/b $ echo data >src/a/foo $ rsync -a src/a/ dest/a/ $ find . -ls 1880052 0 drwx------ 4 matt matt 96 Feb 25 12:07 . 1879989 0 drwx------ 3 matt matt 96 Feb 25 12:07 ./src 1880376 0 drwx------ 2 matt matt 72 Feb 25 12:08 ./src/a 1880793 4 -rw------- 1 matt matt 5 Feb 25 12:08 ./src/a/foo 1880792 0 lrwxrwxrwx 1 matt matt 1 Feb 25 12:07 ./src/b -> a 1880779 0 drwx------ 3 matt matt 72 Feb 25 12:07 ./dest 1880784 0 drwx------ 2 matt matt 72 Feb 25 12:08 ./dest/a 1880794 4 -rw------- 1 matt matt 5 Feb 25 12:08 ./dest/a/foo $ rsync -ni -a --relative src/./b/foo dest/ cL+++++++++ b -> a >f+++++++++ b/foo $ rsync -i -a --relative src/./b/foo dest/ cL+++++++++ b -> a Notice that rsync itemized creation of b/foo on the dry run but not on the real run. I tried to test this with the current CVS rsync, but it hung on the dry run, which probably indicates a separate bug.
CVS rsync now produces the same incorrect output on the dry run as rsync 2.6.9 instead of hanging.
Rsync now sends implied directory elements as directories, which avoids this problem. This is a much saner way to interpret a full path, IMHO. In the test case below, rsync will now output that it is creating a directory "b", and its file "foo". If the user wants the old result, the required command would be to copy the symlink (src/./b) and the referent directory (src/.a/) explicitly.
Good. And if I pass both src/./b and src/./b/foo as source arguments, the symlink is dropped during unduplication.