Bug 4787 - add support for --max-delete=N where N is less than 0
add support for --max-delete=N where N is less than 0
Product: rsync
Classification: Unclassified
Component: core
All All
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2007-07-14 21:03 UTC by Mike Frysinger
Modified: 2008-07-26 10:10 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2007-07-14 21:03:53 UTC
currently the --max-delete=N behavior is:
N > 0:  delete N files
N == 0: delete no files
N < 0:  delete no files

perhaps for N < 0, the behavior could be "infinite" ?  or have it precalc the number of files to delete and delete that many files plus N (so if N is -5 and there are 20 files to delete, rsync would actually delete (20 + N) -> 15).
Comment 1 Wayne Davison 2007-07-15 00:00:27 UTC
The behavior or N < 0 is infinite deletions when specified to 3.0.0, but you're better off omitting --max-delete or specifying --max-delete=2147483647 if you don't know what version the client is.  The old behavior of --max-delete=0 was unlimited deletions when specified to older rsync versions, which is why an rsync 3.0.0 client will terminate a transfer with an older rsync server if that option was specified.  (And the docs warn you to be sure to only specify --max-delete=0 to a 3.0.0 client.)
Comment 2 Mike Frysinger 2007-07-15 00:16:54 UTC
that works for me, thanks
Comment 3 Wayne Davison 2007-07-15 00:53:08 UTC
I changed my mind after noticing that older version used to treat --max-delete=-1 as "halt all deletions".  This gives us a way to communicate our max-delete desires to any rsync in a compatible manner.  I'm changing the code to pass --max-delete=-1 to the server when either --max-delete=0 or a negative value was specified to 3.0.0.
Comment 4 Wayne Davison 2007-07-15 00:58:51 UTC
So, the only supported way to specify "unlimited" is to omit the option or to specify --max-delete=2147483647.