8

I always wondered why rsync tries to transfer a file to a remote location where it has read/execute permissions for the target dir, but no write permissions to create the actual destination file. This can be simulated even locally when trying to copy a file as a regular user to /, rsync will transfer the whole file (also taking rather long for large files) and finally fails with

rsync: mkstemp "/.myTargetFile" failed: Permission denied (13)

So it already seems to fail at startup when trying to create the temporary file (the dot-file) during transfer. Why doesn't it notice this and aborts early instead of trying to copy the whole file without having any write permissions?

And where does it copy the file to if it can't create the temporary file? I can't see any memory increase of the rsync processes and also no corresponding file in /tmp. Seems like it directly discards the data at the destination but still keeps on with transferring.

|improve this question
5

If you need to copy into a directory without write permission, add --inplace to command options. This is sometimes cheaper that it doesn't create a temporary copy, but during updating the file is in inconsistent state.

On the question why it doesn't check own rights beforehand: it could miss some additional specifics as extended access ACLs, so rsync doesn't believe into standard 3*3+3 scheme. OTOH this intentional policy doesn't make any real difference in result - anyway file isn't updated.

|improve this answer
  • Thanks for your reply, but that's just a vague guess and doesn't really answer my question. Even with --inplace it transfers the whole file until noticing the lack of write permissions. – scai Nov 23 '12 at 9:58
  • 1
    While this does not answer OP's help, using --inplace is very useful when you have rights to write to a file but not the containing directory. – tokland Nov 30 '17 at 10:06
  • but that was my solution (I had tmp-files generated but not renamed to the originale name) ,so thanks and up – roothahn Aug 28 '18 at 19:47
4

This seems to be a shortcoming of the current rsync protocol as explained in the bug tracker. The rsync protocol can't determine beforehand if it has write permissions at the target. Instead it just sends and checks for success or failure afterwards.

|improve this answer
2

Rsync creates temporary file at the same folder of target file, so in this case, you must be copying some files to /, since you didn't launch it as root, and normally / was writable only by root, so it fails.

To find out what files is being copied, pass in the parameter -v

|improve this answer
  • 1
    I know that rsync creates its temporary files in the same folder as the target directory. But even if it can't create those temporary files it sill starts the transfer and fails afterwards instead of checking right at the beginning if it has all required write permissions. I want to know why it behaves like that. – scai Sep 12 '12 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.