rsync - Nov 2009 - Possibility so that --max-size AFFECTS --delete ?

Hello rsyncers!

PRACTICAL CIRCUMSTANCES:

Backup1 shall be identical to Original. My traditional custom. NO HELP  
NEEDED for this.
Backup2 shall only be a subset of the original, only files with a  
certain maximum size and filename/suffix pattern get included. For  
this I use rsync's filename filters and size limitations! HELP NEEDED  
here! Thanks!

QUESTION:

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.

The manpage of rsync 3.0.6 for option --max-size reads:
[...] This option is a transfer rule, not an exclude, so it doesn't  
affect the data that goes into the file-lists, and thus it doesn't  
affect deletions. It just limits the files that the receiver requests  
to be transferred. [...]

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

Regards, Stefan Nowak



=== MY PARTIAL BACKUP SCRIPT ==
rsync \
--protect-args \
\
--recursive \
--one-file-system \
--links \
--hard-links \
--times \
--crtimes \
--perms \
--owner \
--group \
--acls \
--devices \
--specials \
--xattrs \
--fileflags \
--force-change \
\
--verbose \
--stats \
--progress \
--itemize-changes \
--human-readable \
\
--delete \
--delete-excluded \
--max-size=10k \
\
--filter="merge "$HOME"/bin/sync-home-dir-partially.filter"
\
--prune-empty-dirs \
\
$HOME/ \
/Volumes/backup/$HOME/

=== MY FILTER FILE ==
## INCLUSION LIST
### 1a) Include all dirs (so that rsync can recurse down).
+ */
### 1b) Exclude special Mac OS X dirs (bundles). They may contain  
files with valid suffixes! Hence, already exclude them before they can  
get a chance of inclusion.
- *.app/**
### 2a) Include all desired suffixes.
+ *.txt
+ *.text
+ *.rtf
+ *.doc
+ *.docx
+ *.htm
+ *.html
+ *.xhtml
+ *.xml
+ *.wiki
+ *.mathpad
### 2b) Include all files without suffixes (those which do not contain  
a dot). Important on Mac OS X, for those files which still use  
resource forks or type/creator for file type determination. And also  
important for Icon files.
+! *.*
### 3) Exclude anything (else the inclusion list).
- *

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.  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.

-- 
Matt