Re: version 2.2 --remove-older-than behavior changed

Hi,

On 17/02/2023 07:02, [email protected] wrote:
> I really appreciate rdiff-backup and like the new command syntax, so I 
> don't want to sound like a whiner, but like tbsky the change to make "No 
> increment is older than ...." a warning and return a nonzero status code 
> disruptive and a big surprise.

I agree, this is why it has been documented in the changelog with the 
prefix CHG, which exactly means "review this and act accordingly before 
you update".
And I _always_ write in the release notes "Detailed release notes are at 
the top of the changelog. As always, consider especially the changes 
marked with CHG as they might impact your workflow." but who reads 
release notes properly? :-^

> I, and I imagine many others, run "rdiff-backup remove increments 
> --older-than ..." before every backup.  For backups containing slowly 
> changing files, it reports "No increment is older than ...." most of the 
> time.  I would guess that in all my different backups I get "No 
> increment is older than ...." about 1/3 of the time.  I'm happy to see 
> the "NOTE: No increments older than ... found, exiting." message, but I 
> see no reason for an additional WARNING that just clutters the output of 
> my backup script making it more difficult to notice when there a real 
> problems, and especially a nonzero status code that will cause my script 
> to terminate unless I change the shell setting to ignore errors, which 
> means the script won't terminate when there is a "real" problem.

That isn't correct, the script will need to be changed, true, but you 
can use something like:

rdiff-backup <do something>
rc = $?
if [[ $(( rc ^ (2+4+8) & rc )) -gt 0 ]]; then echo error; fi

and hence ignore anything which isn't an error (return codes 2, 4 and 8 
are warnings, and they can be combined; search for "bitwise" in the bash 
manpage for details).

_and_ you can do something else with the return code, which you couldn't 
do before, like reporting warnings with a lower severity in your 
monitoring system. In the past, a return code != 0 could mean anything, 
now I'm trying to sort this out properly, so that people can rely on it 
to take decisions, trigger monitoring, whatever. There is still a lot 
more to be done to reach this state of bliss, but Rome wasn't built in 
one day.

KR, Eric