When transferring large datasets where the destination is not consistent anyway until the transfer is complete I use --inplace.
Part of using rsync is that I can interrupt the transfer and restart it without wasting bandwidth.
interrupting rsync causes the file to be left in "mode 0" state. (indicates it's not complete, I can understand this.)
restarting rsync causes rsync to fail opening the file, then it seems to ignore the returned error code, next it transfers the whole file, and looses the result.
Suggestion: As the file is mode 0 during the original transfer anyway, the mode of the destination file should not be considered "holy". If the open fails, attempt to chmod the file to mode 600 and retry.
This is "wrong" if the destination user explicitly chmods the destination to owner-read-only to prevent rsync from messing with them.
How about leaving the incomplete file mode "200" instead of "000"?
Or drop the "--inplace" for this file (which would have made it a full no-op in my case).
I apologise for reporting this on such an old version, but I'm not set up to compile rsync on a whim.
This was fixed in CVS back on July 30th: a newly created file is now created with owner read/write permissions, which allows an interrupted transfer to continue to update the new file.