Joplin relies on timestamps when syncing, so this sounds somewhat right. You could test the same yourself, e.g. by changing the OS time manually to a different zone.
Edit:
The above is likely incorrect. See below for explanation.
@3ter I see from the screen shot you are using E2E encryption. When you set up the new Joplin, did you set the master password before setting up sync, or did you just set up sync and only enter the password when prompted? I have known entering the master password beforehand on new client setup to cause issues
Iām pretty positive I set up sync and then the encryption password. I remember opening up End-To-End Encryption (E2EE) | Joplin to make sure I do it correctly.
Thereās not much here to go on, but again looking at your screenshots I can see that there are very few updates and deletions, but the vast majority are fetch, and there a quite a lot of creates too, though much less than the fetches - Iāll just ignore the creates for now as Iām not sure what they are (Iām guessing somehow new note revisions as a consequence of the many fetches, but thatās just a guess).
Regarding the fetches, Joplin will increment the fetched items count for the number of items checked as part of the delta step of the sync. The delta step uses a context object to basically keep track of the changes that have already been synced up to this point. This context object is stored in the sqlite database and is updated after each successful sync. It basically stores a (epoch) timestamp, which will determine that any files which are modified earlier than this timestamp have already been synced, so donāt bother checking then again. Iām guessing that the context object on your desktop client may have somehow got reset, so that the delta step has to then rescan all files on the server. Not sure what would cause that to happen though.
Would you mind sharing a log file from your desktop client?
Ok, looking at the logs it seems that all your notes have been deleted and recreated, but it happened over the course of a couple of days (27th-29th July), so all the fetches in the sync status were a followup sync action as a result of deletion and recreations in a previous sync cycle.
Just to be clear, when you synced the new device, you did not do any kind of jex import did you?
Assuming you did not, I think the issue is related to encryption keys as per my initial response. I can see from the logs that you did set up encryption correctly on this occasion (when you set up a new device on holiday), but it seems that at some point in the past you may have made an error when you set up the encryption. I can tell this from entries like this, which are seen throughout the logs:
Right ok. As the other keys are disabled and havenāt been updated for years according to the screenshot, they should not cause any problems.
I had another look at the logs and looks there were thousands of fetches that happened before the many delete a create entries, as well as after them. I cross referenced some of the object ids from the deleted entries though, picking some random ones at the lower and upper fetch entries, and they were all revision objects (note history).
It seems like something weird has happened with the revision maintenance. For some reason, when you set up the new client, it created many new revisions which were then uploaded to the server. Then when you came back, the desktop client considers those revisions to be expired, so deletes them locally and on the server. You can see this by following the journey of one of the revision ids like so:
2025-07-29 05:52:11: Synchronizer: Sync: createLocal: remote exists but local does not: (Remote b75c13eac24e43e6bfef9823217c9d01.md)
2025-07-29 06:02:10: DeleteAction: Revision.deleteOldRevisions: ; Item IDs: ["b75c13eac24e43e6bfef9823217c9d01","fc3c6d349ceb4639ae1aae32e087595b","b11aa997aaa74b2ca8ad15ab51ac9ca8","37319e123de84aa1aa0dd521a67394db","18f273adae4741faa09c43c3d14ef17d"]
2025-07-29 06:35:12: Synchronizer: Sync: deleteRemote: local has been deleted: (Remote b75c13eac24e43e6bfef9823217c9d01)
Could you please share a couple more things? On Joplin desktop go to the help, synchronization status screen and send over a screenshot of the totals shown there.
Also, can you please let me know what value is set for ānote history keep forā setting, for both your desktop and mobile clients?
In your log file there are 1360 occurances of Revision.deleteOldRevisions, 12 of which were in June and the rest from 27th July onwards. Thatās just a bit more than the total number of notes you have, and now you only have 387 revisions which is not much in comparison.
Itās quite baffling to be honest. The only other possible thing that might help is if you could send over the log from your iphone as well to determine if the revisions which were downloaded from the server were created on the iphone or if they already existed. Also is the iphone app on the latest version?
Unfortunately I already removed the app from my iPhone because I was a little frustrated . I take it as baffling then.
PS Other apps I adore also handle this time shift pretty ābafflingā: tasks.org also touches everything and to make it worse it also shifts so the times are off at the new locationā¦ Reddit - The heart of the internet. To quote the valued (Iām a sponsor) developer:
Yeah, this is a long-standing issue. Tasks doesn't have a concept of time zones so everything is stored as local time relative to where it was created. I would like to fix this I just don't know when that'll happen
Yeah thatās fair enough. Iām not convinced that the time shift was the cause of this, as timestamps do look the be handled consistently (and timezone agnostic) throughout the application when looking through the code relating to sync. I think the issue more likely arose due to something to do with a new device being setup. But I canāt tell you what caused it either.
All I can say is it may have been a one off due to your profile being in a dodgey state somehow, but I can see from your sync status that everything is all good now and note history cleaning is up to date now if there was some sort of cleaning issue. So this may not happen again, but nonetheless if you want to avoid the possibility that it does, then it would be best to do a new device setup before going away.
):
