Possibility so that --max-size AFFECTS --delete ?

[Stefan Nowak]

Hi!

On 2009-11-28 at 03:43 +0100 Matt McCutchen wrote:

> On Sat, 2009-11-28 at 00:06 +0100, Stefan Nowak wrote:
>> Is there a possibility, so that --max-size AFFECTS --delete actually?
>>
>> Situation where it makes sense: Imagine that I had the rule --max-
>> size=1M and my backup-storage is satisfying. But one day it ain't
>> enough anymore, and I decide to lower down to --max-size=512K. The
>> files larger than 512K at the destination DO NOT GET DELETED!
>> Currently the only solution is to rm -r /my/backup/* and then start
>> the process again with the new size limitations.
>
> Rsync currently does not have such an option.
>
>> The content of this newsgroup post, makes me think, that in earlier
>> versions --max-size may have once AFFECTED --delete:
>> http://article.gmane.org/gmane.network.rsync.general/12024
>
> That thread was about a different issue: avoiding the deletion of
> destination files that don't match the --min-size or --max-size  
> transfer
> rules.

Does this idea mean, that regardless of the source file list  
(resulting from excludes/includes and size limitations), that files at  
the destination get deleted if they don't match the size limitations?

For my particular interest I want this behaviors:
- If the source file is gone, delete the destination file.
- If the source file is not within the size limitation (min or max),  
delete the destination file (even if that is an older version which is  
still within the size limit!). The destination shall gear after the  
source! If the destination is newer, keep it (--update logic).
- If the source file is later again within the size limit, copy it to  
the destination again.

Is it now clearer? Do I have options? Or not?

> The same issue for file-type transfer rules was:
> https://bugzilla.samba.org/show_bug.cgi?id=4378
>
> But all of these issues are about making the transfer rules behave  
> more
> like ordinary exclude rules (optionally at least), so it may make  
> sense
> to deal with all of them at once.  I have generalized bug 4378
> accordingly.

Thanks Matt, for issueing the bug.