Skip to content

ctdb-conf: Fix handling of unchanged values during (re)load

When loading a configuration file any unchanged values that are different to defaults are incorrectly replaced by defaults.

Loading from a configuration file populates opt->new_value with default_value. If the "new" value in the configuration file is unchanged from the current value then new_value is left containing default_value. Later, conf_all_update() commits new_value to value. This means all unchanged values are incorrectly replaced by defaults.

A similar corner case can occur if a key is repeated, first with a changed value and then with one equal to the original value, a similar problem will occur. Arguably, repeated keys are not well-defined... but they do not cause an error so should work reasonably.

When the "new" value is unchanged from the current value then remove any new_value to ensure there is no change.

The 3rd instance of test 9 could have caught this but the expected output was incorrect. Add 2 extra instances of test 11: one to explicitly test that a no-op reload works as expected and another to test the repeated key scenario.

Note that this code isn't currently exercised so no bug fix is required for current releases.

Checklist

  • Commits have Signed-off-by: with name/author being identical to the commit author
  • (optional) This MR is just one part towards a larger feature.
  • (optional, if backport required) Bugzilla bug filed and BUG: tag added
  • Test suite updated with functionality tests
  • Test suite updated with negative tests
  • Documentation updated
  • CI timeout is 3h or higher (see Settings/CICD/General pipelines/ Timeout)

Reviewer's checklist:

  • There is a test suite reasonably covering new functionality or modifications
  • Function naming, parameters, return values, types, etc., are consistent and according to README.Coding.md
  • This feature/change has adequate documentation added
  • No obvious mistakes in the code

Merge request reports