Clients missing notebooks: possible to re-scan / re-synchronize?

Support
1

Hello,

I am using 2 instances on 2 machines of Joplin for Desktop 2.9.17 (prod, darwin) on macOS Monterey (just upgraded to 12.6.3 yesterday evening and was experiencing this same behavior on 12.6.2), 2.6.10 (prod, linux) on ArchLinux, and Joplin 2.8.1 on Android 13 TP1A.221005.002 (Google Pixel 5). That's a total of 4 clients.

I am syncing through Nextcloud 25.0.3 using the Nextcloud synchronization target, not WebDAV, file system, or Joplin Server (although about a month or so ago I was using the file system target inside ~/Nextcloud).

I am not so sure any logs I have currently will relfect what has transpired (due to the age of the problem) because I have been leaving some conflicts unresolved for some time because I have been too busy to resolve them. I also have some sensitive information stored in Joplin, so if logs are needed, I would prefer to submit them by request.

Basically, all of my clients have a noticeably different set of notebooks from one another, and nearly all of them are showing conflicts. Three of these clients have various numbers of conflicts (19, 12, and 5) and are MISSING notebooks that were once there, just the other day in fact. One client has only 1 conflict, so I'm assuming it's the one with the most accurate tree. It just so happens to be the Android client, which AFAICT, doesn't give me the option of exporting.

It's the missing notebooks that have me worried and not so much the conflicts. So before I make a single move, I am wondering how I can verify if my server has an up-to-date and properly synchronized tree of notebooks and what I should do at this point to get my clients back on track. Can I use the Conflict Resolution Plugin safely without risking data loss? Will my missing notebooks come back after resolving all of their conflicts? Should I delete the local stores on my clients and re-synchronize?

2

After re-reading my post I realized that the ArchLinux package I was using (joplin-desktop-bin) is so woefully out of date that it has been removed from the AUR without me realizing! So the first step in resolving this has been to replace it with the joplin-appimage package, which is at version 2.9.17. It seems quite reasonable that running such an old version may have contributed to the desynchronization that has occured. I really have no other explanation for how I've managed to get in the state I am in. But unfortunately, upgrading didn't magically solve the problem.

Also, I wanted to clarify that certain clients are missing SOME notebooks and other clients are missing OTHERS. For example, say client A is missing notebooks A, B, and E, whereas another client might be missing notebooks B, C, and E, and the other might be missing D and F.

One would think that there is an accurate store of information on the server, so I'm going to run with that assumption. Also, I have NOT been editing so many files on separate machines, so the disconnect must have occurred due to networking inconsistencies. I run Nextcloud on Docker, load balanced over 3 different containers using HAProxy, which have seen a fair bit of reconfiguraton and restarting over the past few months, so it seems any combination of those components could have caused this.

In the interest of avoiding pushing any "delete these notebooks" command up to the server, I decided to delete one client's local store and preferences (backing it up first, of course), then set that client up fresh to see what would happen:

$ mv ~/.config/joplin-desktop{,.bak}
$ mv ~/Library/Application\ Support/Joplin{,.bak}
$ mv ~/Library/Preferences/net.cozic.joplin-desktop.plist{,.bak}

Then I restarted the application. It created 9 remote items (the familiar "Welcome to Joplin" stuff) and then started fetching, very slowly. If memory serves, there are thousands of items that need to be synchronized, and I'm not sure why it's progressing so slowly, but I will let it run. I did attempt to synchronize the Android client and it fetched the 9 remote items that were created from my desktop. It does not appear that any other changes were pushed to the server, which is certainly good news.

I have very strong doubts that ANY of the conflicts that have been generated recently are keepers, but is there a way to import them once this re-synchronization completes, just to check them over?

3

Synchronization complete! And at first glance, it seems the first client to undergo resynchronization is in good shape: no missing notebooks and no conflicts. Now to do the others and figure out a way to import the old conflicts for inspection....

(For ArchLinux, by the way:)

mv ~/.config/Joplin{,.bak}
mv ~/.config/joplin-desktop{,.bak}
4

By swapping directories around, I can get my old state with conflicts and missing notebooks as well as the new state with no missing notebooks or conflicts.

However, if I right-click a conflict and choose Export, it seems conflicts cannot be exported, no matter what format I choose:

  • Choosing JEX format produces the message "Could not export notes: There is no data to export".
  • The HTML File format produces the message "Could not export notes: Error: ENOENT: no such file or directory, stat '~/myexport.html'".
  • The PDF format produces the message "Error: ENOENT: no such file or directory, stat '~/.config/joplin-desktop/tmp/{hash}.html'".
  • The MD format (with or without front matter) creates a directory called _resources but no other files.
  • The RAW and HTML Directory formats do nothing at all.

To get around this, I simply used copy and paste to compare the contents of each notebook. Fortunately, the conflicts on each client, although different in number, were the same.

5

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