Selective propagation of deletions, + rsync scope

Matt McCutchen matt at
Thu Jun 2 16:03:51 MDT 2011

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.

> But really as I already said this kind of thing is probably outside of 
> rsync's scope. The reason I said this could really be easily outside the 
> expected scope of rsync to ever provide an answer for is that this is 
> really pretty arbitrary high level application specific oddball 
> behavior. rsync for all it power and flexibility is still essentially a 
> low level and agnostic utility like cp or tar. It's some other higher 
> level script or application's job to decide what to copy and where and 
> when and why. It's only cp's job to copy a file as directed.
> But it's not black & white either. rsync is in fact specifically 
> intended to be a whole lot more than cp. It's by definition and by 
> design a rather more high level, feature rich, powerful, flexible tool, 
> and aims, and succeeds, in providing many and various ways to express 
> even very complex rules to govern file transfers. So it's entirely 
> possible to someday invent some generic feature that might be used in 
> any number of scenarios, and which this one might be just one example it 
> serves.
> Almost all of rsync's features could be argued either way, that they are 
> doable from without, and therefore should be done from without instead 
> of from within. But if that was really the only guiding principle then 
> rsync would not be very useful today, like a special cp with one twist, 
> and we'd all be using something else since most people have more complex 
> needs than that.

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.

> I don't know what your argument is really. Do you suppose I am attacking 
> rsync or Wayne or anyone else such that they need defending?

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.  If
you think a different maintenance approach would give a product that is
better for some set of purposes, it is your prerogative to try it, in
collaboration with anyone you think might have similar goals.


More information about the rsync mailing list