Prior to 2.6.8 I was able to see which files would be deleted using: rsync -t --delete -R -z -C -l --safe-links --exclude [...] -n -r -v . (multiple --exclude options and files removed for brevity) Now when -n is removed, files are deleted that weren't reported when -n was specified.
I could not reproduce this behavior from the information you gave. Could you please find the simplest case of source and destination directories in which rsync exhibits the bad behavior and then post tar files of the source and destination directories in their original state?
I have observed this same problem in the rsync that was recently installed in fedora core 5 updates (rsync-2.6.8-1.FC5.1). The -v switch corrects the problem. I can post the tar file if you want, but I don't think you should need it. I give you the recipe instead. Observe. I just copied the first tmp file I could find into test2 and without -v, it is not mentioned. [pauljohn@pols125 ~]$ cd /tmp/ [pauljohn@pols125 tmp]$ mkdir test1 [pauljohn@pols125 tmp]$ mkdir test2 [pauljohn@pols125 tmp]$ cp VitaePosted.lyx test1/ [pauljohn@pols125 tmp]$ rsync -ran test1 test2 [pauljohn@pols125 tmp]$ rsync -ravn test1 test2 building file list ... done test1/ test1/VitaePosted.lyx sent 121 bytes received 32 bytes 306.00 bytes/sec total size is 6047 speedup is 39.52
Paul, all you are seeing is that, as of rsync 2.6.7, -n no longer implies -v (see OLDNEWS) and you have to provide -v yourself if you want information on what would be changed. A mismatch between what rsync says it will do with -n -v and what it actually does is more worrisome. If anyone can find a reproducible test case for Dave's problem, please post it.
Same situation with this month's outdated files and it displayed the files to be deleted, so I can't explain what I saw when I filed this bug since nothing else changed since then that I'm aware of. However, I don't control the client rsync version.