Selective propagation of deletions

[Brian K. White]

On 6/2/2011 11:28 AM, Matt McCutchen wrote:
> On Wed, 2011-06-01 at 17:08 -0400, Brian K. White wrote:
>> There are other problems too, relating to the difference between "This
>> directory was deleted from the source and so you DO want to delete it in
>> your mirror.", vs "This directory was removed only because the entire
>> tree was removed because we are no longer supporting this old version of
>> the distribution, you probably do NOT want to delete it from your
>> private copy just because we removed it from our public site."
>
> You could have just asked this on the list (or even read the docs and
> found the answer yourself).  Just write protect filters for the
> directories that should be treated that way.  If appropriate, the source
> could even provide filter files in-tree for you to use.
>

What do you mean "directories that should be treated this way"?
That question, plus the inability to distinguish an admittedly tidy 
work-around from a solution makes me think I am wasting keystrokes here 
but let's answer the charges just for the record if nothing else.

The very same directories will have files being deleted for a while, and 
during that while, the deleted files from the source should be deleted 
from the destination. Then at some point they will be either still 
present but changed and mostly empty, or present but completely empty, 
or not-present.

The disappearance of a file because they were all deleted at eol is 
indistinguishable from the disappearance of a file because it was 
replaced with a newer one.

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. That may or may not be practical 
because it depends on just how the distribution source happens to want 
to organize files and manage ongoing turnover.

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.

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?

-- 
bkw