Rustic doesn't check if repo is already initialized

[jfreax]

Hi everybody,

I tested out some new rustic configuration (a new profile file) and mistakenly re-init one of my already used repos (copy & paste errors are saying "hi!"). This repo is actually only the hot repo (there is also a cold one, which is not affected).

First thing first: Why is it possible to simply re-init a repo without any warnings? It will create (at least) a new key (the old one was still there in my case (S3)) and overwrites the config file. Some kind of fail-safe for future dump-asses like me would be great :)

Anyway, it did what it did. At first I couldn't access the repo at all. I then tried to restore the config file from the cold repo and copied it over to the hot repo. When I then tried to access the repo I got this error message:

error: keys from repo and repo-hot do not match for opendal:data#opendal:metadata. Aborting.

I deleted the second key (generated by the second init command) and got this:

error: repo-hot is not a hot repository! Aborting.

Which is more or less expected since I used the config from the repo-cold bucket :(

My question now is, how can I repair this? Can I regenerate a new hot config? Can I somehow just switch the flag in the config file from cold to hot and then it will work? How? Or am I lost here and I need to start from scratch?

Thanks a lot :)

[simonsan]

I transferred the part of re-initializing an existing repository to its own issue, that you can subscribe to here: #1141

[aawsome]

@jfreax To overwrite an existing repository config should actually not be possible. We'll have to investigate this. Most likely you found a bug. Thanks for reporting!

My question now is, how can I repair this? Can I regenerate a new hot config? Can I somehow just switch the flag > in the config file from cold to hot and then it will work? How? Or am I lost here and I need to start from scratch?

Yes, using the cold repo and adding the "hot repo" flag in the config is what should work. I have to look if you can already do this with a recent rustic version. Full repair support should be available once #324 has been tackled.

[jfreax]

I was able to fix it myself. I forked rustic_core and removed the check if the config has the hot flag set (see [1]).

I then forced a config change by using the example from [2], which created a new config file with is_hot set to true. After uploading the new config to my S3 repo, I can finally access my repository again :)

[1] https://github.com/rustic-rs/rustic_core/blob/ef0c568ce2a1f120f7ffed08bcc50e5996b4abf7/crates/core/src/repository.rs#L630
[2] https://github.com/rustic-rs/rustic_core/blob/main/examples/config/examples/config.rs

[aawsome]

Very good! Also great to hear that using rustic_core as library made your life easier fixing it yourself 👍
Actually besides #324 I think there is a use-case that people might have some existing repository and decide to move it to a cold storage. In that case a command like rustic init --only-hot which just generates a new hot repo part from an existing cold repo part would be very useful... But such a command is a bit more involved than simply generating a config repo file. It has to also copy all key, snapshot, index and tree pack data files. But in general nothing too complicated... I opened #1142 for it.

[jfreax]

Using rustic_core helped a lot. Unfortunately, it wasn't still that straight forward. There is no way to simply manipulate the config file. You can only do that indirectly, because most functions are private. I wished for an easier way to read out the config file and to write it back.

Anyway, it worked. It wasn't too tricky. Great project overall! :)

[aawsome]

Yeah, we started to expose only a high-level API. So we don't have to bother too much if we do internal refactoring. And there is quite some room for refactoring of internals, to be honest. But we first start with implementing integration tests on the high-level API, then we can refactor in a much more safe way...