rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Zolf
Subject: Re: version 2.2 --remove-older-than behavior changed
Date: Fri, 17 Feb 2023 08:06:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

Hi,

On 17/02/2023 07:02, qx6uwumzvv@liamekaens.com 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]