Selective propagation of deletions, + rsync scope

Matt McCutchen matt at mattmccutchen.net
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.

-- 
Matt



More information about the rsync mailing list