What Happned: On the source, a directory with files is changed to a symlink. rysnc -ra --delete-after will then generate the following message: rsync: delete_file: rmdir "/tmp/rsync.bug.11080/dest/somedir" failed: Directory not empty (39) rsync error: some files could not be transferred (code 23) at main.c(791) What I Expected: I expected the directory to be replaced with a symlink (like --delete would have done) OR I expected the directory to be deleted at the end (because of --delete-after) but the symlink not to be sync'ed. I would expect it to still raise an error, but the next run would fix it (since the directory is done). OR I expected the error message to explain how I could fix this problem. I can see why it would fail during the sync phase, but the delete phase should have deleted it after the syncing part, since no IO errors were detected on the sending side. I have attached a simple script to generate this error on command. Ciao!
Created attachment 2034 [details] A test case This script will leave a /tmp/rsync.bug.NNNN directory around if it fails (which it does in the current version of rsync). You may want to clean up after the script before running it so that only one directory hangs around. Ciao!
Firstly, thanks for the detailed bug-report. This bug was fixed in 2.6.7: - Got rid of the need for --force to be used in some circumstances with --delete-after (making it consistent with --delete-before/-during). So, you can either upgrade to 2.6.8, or use the --force option when using --delete-after.