Bug 7823 - Documentation enhancement for --inplace option
Summary: Documentation enhancement for --inplace option
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All Linux
: P3 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-26 07:12 UTC by Erik Logtenberg
Modified: 2011-01-01 20:19 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 Erik Logtenberg 2010-11-26 07:12:27 UTC
The man page lists 5 limitations of the --inplace option, one of those is:

(4) a file that does not have write permissions can not be updated

A small enhancement of the man page would be to specify that this limitation doesn't count for the root user. In other words the limitation is not that rsync would check the file permissions and refuse if it doesn't have +w, instead rsync simply tries to write anyway and if that works (i.e. the user is somehow allowed to write to that file regardless of file permissions) all is well.

In my case, /etc/shadow can in fact perfectly be backed up with rsync --inplace, despite the -r-------- permissions. In order to be able to read that file, rsync was running as root anyway.

Secondly, the man page gives a hint for possible use cases of --inplace:

This option is useful for transferring large files with block-based changes or appended data, and also on systems that are disk bound, not network bound.

A use case that will become more and more relevant these days and in the near future is the use of copy-on-write filesystems, that also support snapshots, like btrfs. In that context using --inplace can seriously increase disk space efficiency, because the fs then only has to store the changed blocks.
Comment 1 Wayne Davison 2011-01-01 20:19:48 UTC
Thanks -- I've clarified those issues in the master branch of git.