Home / GitHub Page

Joplin and joplin-desktop create separate configs?

This seems like a bug, except I doubt it’s implemented this way by accident, so I wanted to bring it up here instead of as a github issue.

When I run joplin (CLI) for the first time, it creates a ~/.config/joplin directory. When I run joplin-desktop for the first time, it ignores the notes in CLI and makes a separate ~/.config/joplin-desktop directory.

If this is by design, what’s the rationale? It looks like if I make one of these a symlink to the other I can see the same notes in each, but I have a feeling this will end badly for me if there’s a reason why they were using separate config directories in the first place.

Can someone clarify, please?

The Sqlite database doesn’t have built in conflict resolution, so one change in one app might overwrite a change in the other app. There might also be other state that’s kept in app memory and that will conflict.

That’s why the two apps should have two different profile dir, and you can use the sync feature to keep them in sync.

Or if you really don’t want the duplicity, you can make the terminal app use the desktop profile (search the forum). Keep in mind though that if you run both the Desktop and the Terminal app at the same time, you might damage your database just the way Laurent described, and you’ll have no-one but yourself to blame. :wink:

Could not assume myself to have doubled all notes just to use 2 separate interfaces.
I’m not coder to help, but wouldn’t be fine to split user interface from backend processing engine?

Then various UIs (text, GUI, API, web,…) will communicate through the same backend and the data consistency is assured.

1 Like

I use 3 entries point to the same profile folder without any problem
just as it has already been explained : do not start joplin + joplin-desktop in the same times.

Just to be clear, sharing profiles between instances might lead to very hard to explain sync issues, or loss of data. It just needs to happen once where you forget than one instance was open, and you probably won’t even realise you lost data till many days or weeks later, and by then you’ll assume it’s a bug in the app.

So for these reasons, it’s not recommended at all to share profiles.

1 Like

I’ve created a fresh .config dir for the joplin cli and will rely on Dropbox, but I want to signal boost the point that @Rado1 makes: is there a good architectural reason for why the different frontends don’t share a common back-end? Seems that would help resolve issues like this and reduce what I assume must be a fair amount of duplicate code. Just curious what the rationale is, or if the current approach is just what grew organically.

…ah, I see joplin server starts an “experimental” API server. Is this intended as a first move in that direction?

The frontend uses the database for states. If you changed a state in one frontend and the other frontend had another state in memory, but the corresponding data in the database was different, you’d have a disaster in the making.
It’s the typical distributed access problem. e.g. 2 database servers cannot use the same database on disk. If you wanted to that, you’d have to install a cluster service which acts as a CF (coupling facility) and/or quorum. Developing a CF or quorum system is not in the scope of this project.

1 Like

Only one backend will work with the database. Any state of the frontend is passing to backend through API.
All frontends will communicate through this one backend therefore data will be (should be) consistent…
Is it a bad idea?

no but take care of that: