Bug 3978 - readonly source -> incomplete transfers (permission problems)
Summary: readonly source -> incomplete transfers (permission problems)
Status: CLOSED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.4
Hardware: x86 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-30 01:31 UTC by Roger Wolff
Modified: 2006-10-15 13:26 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Wolff 2006-07-30 01:31:00 UTC
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.
Comment 1 Wayne Davison 2006-09-17 19:50:15 UTC
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.