Details
-
Bug
-
Resolution: Fixed
-
Major
-
6.6.0
-
Untriaged
-
1
-
No
Description
What's the problem?
The easiest way to display this issue is with a set of steps:
1) Create an empty S3 bucket
2) Use cbbackupmgr config to configure an archive/repository in the given bucket
3) Use the 'aws-cli' to recursively remove everything in the bucket
4) Use cbbackupmgr config to configure the same archive.
cbbackupmgr will error out stating that the archive already exists (which to it's knowledge it does e.g. it exists in the staging directory). Then then continue with the 'exitIfError' logic leading to the archive '.backup' file and logs being created in the remote archive.
We now have an archive without a repo in the S3 bucket and a complete archive/repo in the staging directory. If the staging directory is then removed, then we have lost that archive, nobody knows whether it exists anymore.
Obviously this is only a toy example. If the user was to use a different archive with the same staging directory, then archive '.backup' file would be clobbered.
How should it be fixed?
We can nip this in bud by simply throwing the correct error when the user is trying to use an populated staging directory for a remote archive which doesn't exist. We should also add an extra flag to 'PutArchiveMeta' to ensure that the only subcommand which can upload the archive version file is config. This should ensure we don't modify the version file any more than we need to.