I fell victim to a funny behaviour of rsync. I'm using rsync 3.0.5 under Ubuntu Linux 9 to copy/sync data from one local disk to another, e.g. to a USB harddrive which will be mounted e.g. under '/media/usbdisk'.
However, as long the USB drive is not mounted this mounted directory is root owned and write protected for normal users (to protect them to accidentally copy files to the wrong physical drive).
Now, if rsync is used to copy data to this or any other write protected directory the input data seems to be processed as normal. The --progress (-P) option shows the copy process as normal - sometimes with a very high speed (e.g. 80 MB/s), sometimes with the read speed of the source media (ca. 20MB/s). No error appears until the end, then the following message is printed for every "transfered" file:
"rsync: mkstemp "/mnt/tmp/.<file>.eBXcOU" failed: Permission denied"
Of course no files, neither a temp or the final file, are created at the destination (because the user does not has write permissions).
It looks to me that the rsync server accepts incoming data while the (temp) file the data should be written to could not be opened! The error message which occurs at the beginning is only passed to the client at the very end! This behaviour does not make sense and can cause a lot of time being wasted.
The same happens for remote copy operations if the destination directory is write protected. In this case bandwidth is also wasted.
rsync should skip files and print the appropriate error message immediately after the server fails to open the (temp) destination file.
This is a known drawback of the current rsync protocol. Fixing it would require major changes to the protocol. Since there is no correctness issue, I would tend to consider this an enhancement request rather than a bug.
There were multiple Debian bugs about this. I merged them all here: