The command % rsync --delete --max-delete=3 seems to permit 4 files to be deleted. In general, --max-delete=N seems to allow N+1 deletions. Moreover, --max-delete=0 appears to allow an unlimited number of deletions. (However --max-delete=-1 allows none.) [Editorial: I realize that some cmds give an alternative interpretation to an argument of zero. However, since a user might well write a wrapper around rsync, using "--max-delete=0" to protect himself, I see a good reason to have --max-delete=0 block all deletions.] Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r15 (default-linux/x86/2004.2, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10 i686) ================================================================= System uname: 2.6.10 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 8 2005, 00:24:24)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/X11/app-defaults /etc/X11/gdm /etc/X11/rstart /etc/X11/xdm /etc/gconf /etc/hotplug /etc/sound/events /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS=" http://open-systems.ufl.edu/mirrors/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apm arts avi bash-completion berkdb bitmap-fonts cdparanoia cdr clisp composite crypt cups dvd dvdr emacs encode esd evo f77 fam flac font-server foomaticdb fortran gdbm gif gimpprint gnome gphoto2 gpm gssapi gstreamer gtk gtk2 imagemagick imlib ipv6 irmc java jpeg kde kerberos ldap libg++ libwww mad mikmod mmx motif mozilla mpeg mysql mythtv ncurses nls nptl oggvorbis opengl opie oss pam pda pdflib perl png python qt quicktime readline sasl scanner sdl slang spell sse ssl svg svga t1lib tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
glanced at the source code and it has many checks such as this: if (max_deleted && number_deleted >= max_deleted) return; to address the 'N+1' issue the >= could probably be changed to '>' ... to address the '0 means infinite', i think suitable behavior should be: -1: infinite 0: none 1+: 1+ logic would require setting max_deleted to -1 by default and then perhaps changing the check like if (!max_deleted || number_deleted > max_deleted)
Perhaps this is my background as mathematician speaking: if possible, I'd have negative integral values for --max-delete mean no transfers. (Decrementing, in a loop, the argument to a program, I've been a few times bitten by the program "discontinuously" interpreting its argument.) Perhaps the empty value could mean "infinity", i.e there is NO --max-delete. Having said that, I'm thrilled that `rsync' exists, and I'll adapt to any argument convention...
with this kind of behavioral change i think we should go through upstream dev lists to get this done ... you can purse it here: http://lists.samba.org/mailman/listinfo/rsync if you dont wish to, just say the word and i'll drop a note upstream and see what they think of the idea ...
Yes, thank you for the offer, please pass it "upstream".
spanky: you offered to take it to upstream, your call on the bug
latest rsync treats N as N and not N+1: http://lists.samba.org/archive/rsync/2004-October/010852.html i'll file an enhancement request upstream for --max-delete=-1
