Web Gui can't open existing repository

Please describe what you are doing to trigger the bug:
Start web gui, Storage, select folder with a previously initialized repository (from CLI)

Please describe what you expect to happen (but doesn’t):
Open the repository without asking me to initialze the storage (enter password etc.)

Please describe what actually happens (the wrong behaviour):
It asks me to “Configure the storage”, “We are going to initialize the storage…”

i think this will not initialize the already-initialised storage. I believe there is only a working issue here.

This issue arises because since you first initialised the storage from CLI, web-ui doesn’t know anything about it, so in order to use it (decrypt and everything) you are required to add it’s password. (without the password there’s no decryption possible).

@gchen, can’t :d: be a bit smarter here and read the storage folder first (whenever possible) and if it finds the config file and chunks or snapshots folders, then it tells the user that it needs to know the password in order to acces the storage?

It’s weird (from a usability perspective) that :d: (cli in my own case, web-ui in this case) always asks to initialize the repo, even though after i add the password it tells me that “oh wait, i won’t initialize it since it already has been. Here are the actual settings that you used: [bla]”

1 Like

I was scared doing that, because in worst case this could destroy my repository by overriding existing files. I made a backup of the config folder first and tried this – and no, this does not work at all. I do not know what the web ui does, but it does not initialize a compatible repository. It created a binary config file in that folder, and had a snapshots and chunks folder created in the base dir. It clearly did not read the .duplicacy folder.

okay there was a missunderstanding here on my side: i thought you wanted to init a storage (eg. the destination of the backup), but now i understand that you actually want to point web-ui to an already existing repository (i’m understanding this since you mentioned the .duplicacy folder)? Am i correct this time?

btw, In case you want to do this, i don’t think that’s possible. repositories created by CLI won’t be “picked up” by web-ui, since webui repositories are organised differently.

Can you please describe again what you’re trying to do?

As the title says: I want to open an existing repository.
What you write: "i understand that you actually want to point web-ui to an already existing repository " that’s correct! :slight_smile:

Oh this is shocking that the web ui uses a different repository format‽ Shouldn’t the CLI, the old GUI and the web UI be compatible with each other?

They are compatible in the sense that they can share the same storages. but webui doesn’t use the same locations for storing the repository-related configuration files (more specifically the .duplicacy/ folder no longer resides as a hidden folder in your repository, but in a central location). This is why we have to recreate the repositories (init them) inside web-ui as well.

I think it might be worth the effort of providing some assistance for web-ui users who want to use existing CLI configurations. For exanple: how about letting the web-ui detect if a specified repository folder contains a .duplicacy folder and offer to import the settings?

Or if that is asking too much, at least issue a modal informing the user that the existing settings will not automatically be imported and point to instructions for how to do it manually? @gchen



Does this mean that if I replace duplicacy-cli with duplicacy web edition on my computer under linux I will not be able to start from the existing repository ? I will have to start the backups from scratch and lose the backup history ?

No, it only means that the web GUI can’t import information created by the CLI stored under the hidden .duplicacy directory. Following the simple steps on Duplicacy User Guide, you should be able to continue running backups against an existing storage, as long as you use the same backup id as the one used by the CLI.

Hi, perfect it is more clear for me. I will make test. Many thanks