rsync in-place (was Re: rsync 1tb+ each day)

Paul Haas paulh at
Thu Feb 6 03:38:07 EST 2003

On Wed, 5 Feb 2003, Craig Barratt wrote:

> Of course, a major issue with --inplace is that the file will be
> in an intermediate state if rsync is killed mid-transfer.  Rsync
> currently ensures that every file is either the original or new.

I hate silent corruption.  Much better to have things either work, or fail
in an obvious way.

I don't have a need for --inplace.  So someone who does have a need,
should say if my reasoning makes sense in the real world.

For databases, I'd want the --inplace option to rename the file before it
starts changing it, and then rename it back.  With that mode, rsync would
ensure that every file is in one of three states:

    1. original
    2. new
    3. gone (but not forgotten, since the intermediate state file
             would still be there, just with a temporary name)

You wouldn't want the rename in a bunch of situations:
  on systems where renames are expensive
  where it doesn't hurt to have a mixture of old and new contents in a file
  for raw devices, unless you know how /dev really works on your system

This means, that there should either be two --inplace  options, like
 --inplace-rename and --inplace-norename or maybe, --inplace-dangerous and
 --inplace-more-dangerous or a modifier option.  In many cases, writing
the documentation, is more work than writing the code.

Paul Haas paulh at

More information about the rsync mailing list