Selective propagation of deletions, + rsync scope
Brian K. White
brian at aljex.com
Thu Jun 2 17:04:48 MDT 2011
On 6/2/2011 6:03 PM, Matt McCutchen wrote:
> On Thu, 2011-06-02 at 17:43 -0400, Brian K. White wrote:
>> Perhaps the server side could specify all the deleted files and
>> directories as being excluded before they are actually removed from the
>> server. Then the client could use --delete but not --delete-excluded and
>> get essentially the optimal behavior.
> Yes, that's what I meant.
>> Almost all of rsync's features could be argued either way,
> Indeed. Of all the software packages I'm familiar with, rsync seems to
> attract this kind of debate the most often, for precisely the reasons
> you mention.
Heh. Well bash and ksh just built-in a good chunk of an OS. And zsh and
emacs built-in just as much PLUS a plugin architecture that adds
everything else imaginable.
> In the first place, I'm telling you not to expect Wayne to change his
> decision. I'm not sure I would defend it per se, but I have gained a
> great deal of respect for his approach of being selective about features
> and working to make the ones that are there as robust as possible.
Similarly, I don't necessarily need the OP's
suspend-gracefully-with-informative-server-response feature at the
moment. I'm only saying, that I think it does align with existing design
and development thus far.
Many existing features clearly and explicitly exist to allow rsync to be
used as a standalone daemon, and in public settings, and clearly always
strives to be as robust as possible both in itself as well as provide
for as robust as possible usage by the user/script/app.
And, unless someone discovers a trick I haven't spotted yet, as far as I
can tell the lack of this feature does prevent or at least make less
robust that basic intended usage in some situations.
I haven't finished playing with the exclude file idea so it may be that
the difference in behavior of an excluded directory vs a missing
directory vs down service may be detectable from the client and serve as
a good enough replacement for an explicit status code response from the
More information about the rsync