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