I wanted to move the files of a directory (whose path was only slightly different from the current directory) to the current directory. Unfortunately, I errorneously passed the current directory as first parameter instead of the other one. The rsync call was rsync --append -avAHSP --remove-source-files /path/to/current/directory/ . The files in the current directory were deleted. I think rsync should check whether the source and the destination files are the same (like mv does, for instance) and in that case prevent the files from being deleted.
A big _me too_ on this one. "Gee, my main storage space is nearly full, I need to move it off to another disk immediately... It's kinda important so I don't want to use mv and just hope everything goes okay... You know, if I use rsync, I'll get file checksuming, and some stats. Perfectly. Let me just wrap-off a quick cmd-line before we run out of space. Perfect! Hmm, where'd they go? Dammit! 200 GBytes of 'didn't have a chance to back it up yet' data GONE. Thanks rsync!" While I recognize my mistake in all of this, and while important and irreplaceable, the data wasn't critical, but I remain in a mild furor over pretty much the one and only possible way this could go wrong, not being checked for, despite how trivial doing so would be... This is just a complete lack of design fore-thought on a critical-data tool. Combine this with the terrible performance I'm seeing on filesystems with large numbers of files/folders, and my days of promoting rsync are over. I guess it's time I really check out Unison...
Same for me. No data loss here, but a bunch of work undeleting the files and moving them back to the right directories. Files should only be removed if they are actually copied to another location.