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

Matt McCutchen matt at mattmccutchen.net
Fri Nov 27 21:34:13 MST 2009

On Sat, 2009-11-28 at 05:15 +0100, Stefan Nowak wrote:
> On 2009-11-28 at 03:43 +0100 Matt McCutchen wrote:
> > On Sat, 2009-11-28 at 00:06 +0100, Stefan Nowak wrote:
> >> 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?

No.  It means that extraneous destination files are deleted regardless
of --*-size rules.  Protecting destination files that don't match the
--*-size rules from deletion might be desirable if rsync is run both
ways between a pair of directories, as discussed in bug 4378.

> 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 source file is later again within the size limit, copy it to  
> the destination again.

The above text describes a size limit that behaves as a hide without a
protect.  This would be covered under the generalized bug 4378.

> If the destination is newer, keep it (--update logic).

This requirement cannot be reconciled with the others under rsync's
current design.  A hide would omit the large source file from the file
list, and then the receiving side would be unable to do the --update


More information about the rsync mailing list