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
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
