Thank you for contributing to the Bareos Project!

This pr fixes a long standing issue with bareos where one storage daemon can sometimes only request up to 19 volumes from the same pool/mediatype combination concurrently.
This is because the sd has a hard limit of 19 requests to get a suitable volume. As the director does not know which volume is currently in use, its possible to that it returns 19 volumes that are already in use by other devices.

In this pr we upped the limit to (number of devices)+10%. In the future we should make sure that the sd already tells the director immediately which volumes the sd is already using., reducing the number of round trips required.

This also contains a fix for a director crash that happens when it cannot connect to the database. This crash occurs because its not safe to lock the db in such cases (as the lock may not exist yet), but we still want to access the error string (which may be protected by that lock). I added a workaround, so that dbs that failed to open are considered "private" (as they can not have been shared yet!), in which case accessing error string is allowed even without the lock.

Thirdly, this pr contains some cmake improvements which should make it much faster to (re-)configure a bareos build directory. Unit tests are now not parsed via a cmake regex parser to find out which tests exist, but they are executed in a post build to gather that information.

Please check

• Short description and the purpose of this PR is present above this paragraph
• Your name is present in the AUTHORS file (optional)

If you have any questions or problems, please give a comment in the PR.

Helpful documentation and best practices

• Git Workflow
• Automatic Sourcecode Formatting
• Check your commit messages
• Boy Scout Rule

Checklist for the reviewer of the PR (will be processed by the Bareos team)

Make sure you check/merge the PR using devtools/pr-tool to have some simple automated checks run and a proper changelog record added.

General

• Is the PR title usable as CHANGELOG entry?
• Purpose of the PR is understood
• Commit descriptions are understandable and well formatted
• Required backport PRs have been created
• Correct milestone is set

Source code quality

• Source code changes are understandable
• Variable and function names are meaningful
• Code comments are correct (logically and spelling)
• Required documentation changes are present and part of the PR

Tests

• Decision taken that a test is required (if not, then remove this paragraph)
• The choice of the type of test (unit test or systemtest) is reasonable
• Testname matches exactly what is being tested
• On a fail, output of the test leads quickly to the origin of the fault