On a case-insensitive file system (Windows/cygwin): I renamed a file to upper case, then ran my backup script using rsync -r --delete-after src /backup I got this error message: rsync: send_files failed to open "/cygdrive/d/home/tools/mined/src/n/x": Permission denied (13) IO error encountered -- skipping file deletion The old (lower case) file was finally deleted in the backup area, but the new (upper case) file had not been copied to it. (It was copied of course when I ran rsync again.)
Are you saying that it deleted a file AFTER saying "IO error encountered -- skipping file deletion"? Maybe you need some --itemize-changes to make sure. Unfortunately, this is a limitation of the filesystem and rsync *should* have simply left the file untouched (and never be able to update it) unless --ignore-errors. The behaviour you describe is what --ignore-errors should do. The --fuzzy option might possibly help here.
Actually, I was too eager minimizing the test case, sorry. I can only reproduce it reliably with additional options -vltoD : rsync -vrltoD --delete-after src /backup Also sorry for the bogus error message, actually it looks like: building file list ... done deleting src/vivaldi (where a file src/Vivaldi exists, a file /backup/src/vivaldi existed before and is then deleted) Attempts to remove options for reproducing the issue expose weird behaviour; for example, if I strip "ltoD": rsync -vr --delete-after src /backup it also happens initially, but if I repeat the test, it does not happen again until I revert to the previous options (of course with a fresh test case setup each time).
That makes even less sense. Rsync doesn't do anything to the source at all unless --remove-source-files and it only does that after it successfully transfers a file.
The file /backup/src/vivaldi is deleted, not src/Vivaldi
OK, now I understand what is going on. It is a 2-part problem... Rsync sees the source file as new because it does not exist in the target but it fails to copy the file because the name conflicts with an existing file. That should abort the deletions (not sure why it isn't) but in the end rsync sees the existing file as superfluous because there is no matching filename on the source. The --fuzzy option might fix this. Using --delete-before instead of --delete-after would delete then replace the file.