Possibility so that --max-size AFFECTS --delete ?
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