After an rsync, if a directory on the target is replaced by a symlink pointing to a new location containing the original, unchanged, directory content, a verbose dry-run will *not* report that the directory contents from the source will be transferred to the target and replace the symlink (which is what happens during the non-dry-run invocation). I discovered this during preliminary testing prior to using the new 2.6.3 --keep-dirlinks option (which, BTW, works just great in 2.6.3pre1). This bug may be related to bug 1433. The problem occurs with 2.6.2 (and possibly earlier) as well as with 2.6.3pre1. Here's an example using 2.6.2: $ ll -R a a: total 12 -rw-r--r-- 1 jve users 29 Feb 8 2004 f1 -rw-r--r-- 1 jve users 29 Feb 8 2004 f2 drwxr-xr-x 2 jve users 4096 Feb 8 2004 projects a/projects: total 8 -rw-r--r-- 1 jve users 29 Feb 8 2004 p1 -rw-r--r-- 1 jve users 29 Feb 8 2004 p2 $ rm -rf a1 $ rsync -la a/ a1/ $ rm -r a1/projects $ ln -s ../a/projects a1/projects $ ll -R a1 a1: total 8 -rw-r--r-- 1 jve users 29 Feb 8 2004 f1 -rw-r--r-- 1 jve users 29 Feb 8 2004 f2 lrwxrwxrwx 1 jve users 13 Aug 28 02:10 projects -> ../a/projects $ rsync -lavn a/ a1/ building file list ... done wrote 146 bytes read 20 bytes 332.00 bytes/sec total size is 116 speedup is 0.70 $ rsync -lav a/ a1/ building file list ... done ./ projects/ projects/p1 projects/p2 wrote 292 bytes read 60 bytes 704.00 bytes/sec total size is 116 speedup is 0.33
Yes, there are several aspects of a full transfer that aren't reported properly in dry-run mode. In this instance the symlink happens to point to a directory where up-to-date files exist, so rsync is fooled into believing that they won't be transferred. To fix this, rsync will need to keep track of invalidated path prefixes that cause files below them to be marked as not existing. Something to look into fixing at some point in the future, along with bug 1433 and bug 1764.
This is now fixed in the CVS version. It became very easy to fix after some recent changes I made provided the hierarchical depth value for each file, which means that anytime a directory is missing in --dry-run mode, we just need to ignore all items that are deeper in the list up to the next item that is less-than or equal-to the missing depth. Note that there is a potential for the incorrect output to occur when talking to an older rsync (prior to protocol 29). This is because the sort algorithm in earlier rsyncs might put an item from outside a directory's hierarchy in between the directory and its contents. To see this in action, update to the CVS version (also available in the latest "nightly" tar file), add a file named "projects.txt" in the "a" dir of the above test-case, and verify that the --dry-run output works properly. Then, repeat the test with the debug option "--protocol=28" and the items inside the projects dir will not be listed in --dry-run mode (because projects.txt sorted in between the dir and its contents).