init --encryption X
should warn if existing repo uses different encryption
#840
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I've noticed that
init
is designed to be a no-op if there already is a Borg repo at the given location. I don't want to debate that decision, as far as I could tell browsing these issues there has already been some discussion about it.However, I'd argue that if I do
init
, I have to specify the repo's encryption, and therefore should be able to rely on this encryption setting to actually have been applied to the repo.In other words, a successful run of
init
currently guarantees that there is now a repo at the target location, but it does not guarantee that it is actually using the encryption I have requested.Steps to reproduce
PATH
is the path to a repository, but right now, there's nothing at that path (i.e. it's non-existent).borgmatic init --encryption none PATH
PATH
.borgmatic init --encryption repokey-blake2 PATH
Actual behavior
The repo at
PATH
is still not using encryption. However, the call toinit
returned successfully.Expected behavior
init
should check whether the requested settings correspond to what's actually set for the repo.init
should quit with an error status.Other notes / implementation ideas
The basic reasoning behind this is that people are (rightfully, I think) expecting to be able to run
init
in a script and rely on a success status to mean that everything has been created as expected.Note that I only tested this with borgmatic 1.7.7. If this has been already fixed in a more recent version, please disregard this issue, and sorry for the noise.
borgmatic version
1.7.7
borgmatic installation method
Debian package
Borg version
1.2.4
Python version
3.11.2
Database version (if applicable)
No response
Operating system and version
Debian GNU/Linux 12 (bookworm)
Thanks for taking the time to file this and for trying out borgmatic! I can confirm that this ask still applies to borgmatic 1.8.8 (the most recent release as of now).
Yeah, Borg's
init
can't actually change the encryption on an existing repo, soborgmatic init
in this scenario would have to error. Which seems like a reasonable thing to do... borgmatic could introspect the existing encryption mode viaborgmatic info --json
and compare it to the requested encryption mode.However, other
init
flags like append-only mode and storage quota are not (to my knowledge) available by introspecting the repo, and so borgmatic would not be able to check for those.This is implemented in main and will be part of the next release. Thanks again for bringing this to my attention!
Released in borgmatic 1.8.9!