Spurious conflicts after Dropbox move

Operating system


Joplin version


Desktop version info

Joplin 2.13.12 (prod, darwin)
Client ID: 99b05b8b02ba4984ae3f0cda552689ef
Sync Version: 3
Profile Version: 44
Keychain Supported: Yes
Revision: e027cdc
Conflict Resolution: 1.2.3
Kanban: 1.0.7
Markdown Prettier: 0.1.0
Simple Backup: 1.3.5


Joplin 2.13.12 (prod, win32)
Client ID: 3d72550cc54d4b69968d1b8ea68bb3a8
Sync Version: 3
Profile Version: 44
Keychain Supported: Yes
Revision: e027cdc
Conflict Resolution: 1.2.3
Cursor Sync: 2.1.0
Kanban: 1.0.7
Markdown Prettier: 0.1.0

Sync target



Markdown Editor

What issue do you have?

Hi -

My setup:
Multiple computers (work desktop and laptop (both macOS) and home Windows 10 desktop) are synced via Dropbox, where I use the Markdown editor (not an external editor). This worked well, until I had to move my files to a different Dropbox account, as part of a job change. I cloned everything to the new account and resynced with that account. While I know that that can be touchy, it initially seemed to have succeeded - all notes and resources load.

Expected behavior:
If everything were working right, I would be able to edit any file, and a conflict would only occur if the file were simultaneously open on one of the other computers. (I.e. conflicts would be rare.)

Actual behavior:

  • Editing any note - even when Joplin is only open on one computer, even when only one computer is on - spawns a conflict. This occurs with any kind of edit - plain text or resource addition. The edited note shows up in the Conflicts folder. Initially, I do not see a copy of the original in the original location and much of the time, one never shows up, even after synchronization, though this is not entirely reliable and sometimes one does appear when I go back to look at the original notebook.
  • Possibly consistent with there being no authentic conflicting file, the Conflict Resolution plugin generally throws up a "Not Found" message when I try to use it on these ostensibly conflicted files.
  • The note can then be moved back to the original location. If an original respawned (which again is rare), it has a different ID than the edited and restored note.
  • At that point, addition and deletion of notes works as expected (if I delete the original note and move the edited note back into the correct location, both of these things stay completed, and adding a new note doesn't immediately cause a conflict.)
  • If I re-edit a note to which this has happened, it acts as expected: no weird jumps to Conflict.
  • This all occurs even in Safe Mode.

Note: someone has previously described something similar, but their solution of "have a Joplin-only Dropbox" is suboptimal and seems unnecessary, since everything was previously working in Dropbox:

Answering some of the questions brought up in those threads, all computers have the correct time/time zone (GMT-05:00), and Dropbox is also set for GMT-05:00. Note that it's also not secretly syncing to both the former and new Dropbox accounts; I only see changes occur in the Joplin directory at the new Dropbox account. Updating to the newest betas also doesn't seem to have made a difference.

I've attached snippets of the console from when I edited a file and synced as described above, creating a conflict (in this case, no unedited file remained/respawned in the original location), and then when I moved the edited file back to the original location and resynced.

I'd appreciate any help - while I could manually edit each of several thousand notes in several notebooks and move them back to their original locations, and given the behavior exhibited so far that might stop the spurious conflicts, but I'm hoping there is a better answer!

Log file

20230107_joplin-conflicts.txt (4.26 KB)

It might take a bit of time to complete but if you still have a good local copy of your data you could use option within Joplin to just use your local data to replace everything in your sync target (in the sync > advanced section).


Just make sure you have good JEX backups of everything before you do anything.

I ended up doing a full restore from a last-known-good .jex backup (with manual export/reimport of notes that postdated that backup); I was concerned about whether or not I could actually trust the post-move local copy of the data. That does seem to have nuked whatever weirdness was going on - still no clue what in particular caused it, though!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.