For myself I changed the setting to create conflict files and luckily only a handful were created in Dec 2025, now it seems to have settled down - BUT I am now extremely lairy of Sync, which is a shame.
I can attest that even MS struggled with sync protocols when they launched Onedrive, and Google likewise struggle with Sheets being genuinely available on both server and local devices. So I get that it ain’t easy!
But I also have other apps that I trust completely and afaik have never failed to resolve versions. And there are products I guess like Box etc that sync well enough.
So while your assertion is reasonable, me and others on this thread are presenting a clear case - uncommanded deletion /replacement of a legitimate file. It has nothing to do with user interaction - in my case the likely culprit was the Journal setting ‘open Today page on startup’ (which is now OFF!) - no idea if that has been investigated.
EVEN IF the user is to ‘blame’ for working two devices side by side, the sync should be consistent - it should always take the latest timestamp as valid OR create a conflict warning /file if the sync frequency is low. It should never overwrite an existing file with a new one without at least a warning message. If there’s still a bug the ‘automatically merge’ setting should be switched off for everyone at the server until the fix is found.
The time between syncs is maybe a problem, but for power users an elevated paid membership tier could be used to reflect the additional resource required? Or even the cost of the Sync membership increased to cover it for everyone? I would be happy to pay more for certainty.
Not gonna lie, this has shaken my confidence in Sync - and Obsidian itself to a degree (although my primary use case is offline… and Obsidian is AWESOME!!)
The conflict file creation setting triggers a notification when the creation happens, which is good. But the notification should be somehow sticky, so it stays there until explicitly dismissed. I find myself having to check from time to time whether I missed some conflict or not, whether I wrote something already in a note that got “conflicted away” without me realizing or I just didn’t write it yet.
… which is another reminder of how this unreliability undermines the whole idea of using Obsidian as a quick brain dump.
(I tried looking for some plugin that would allow me to detect new conflict files and react to them automatically, but couldn’t find anything useful)
I copied an earlier tip to set a bookmark to the search phrase ‘conflict xyz’ which is appended to the suspect filename - granted this is still manual but at least is just one click away when you need to know.
I have seen them on iOS for sure, and I think in macOS too.
To be clear they’re not OS-level notifications, but small boxes on the top right of the Obsidian window/app that remain there for a few seconds before disappearing. I wonder now if they’re coming from some plugin, but I’ve seen notifications in the same style coming from multiple plugins, so… my guess is they’re from Obsidian itself? I’ll screenshot them next time.
I made the changes a few weeks ago and coincidentally the number of conflicts started to drop off. But today, another one. Obviously now the setting is ‘robust’ it’s not a huge problem - but shows that things are still not peachy in the land of Sync. (in my case between PC and Android versions).
I try to behave sensibly and not try to edit on two devices intentionally - but today I think the PC version did not update to the phone version fast enough - unclear if the phone failed to upload to cloud, or PC failed to download from cloud. Sync frequency may be the only issue in my case now.
Upon opening a note on iOS, it takes a few seconds to load the remote content, and even if no changes were made remotely, the local changes in those few seconds are discarded.
On a number of occasions, Sync didn’t merge the changes when I made edited the same (already existing) daily note first on macOS and then on iOS (both were connected to the internet), but I didn’t notice on the phone that the Mac changes weren’t there (on another topic in the same daily note), and when I looked at the computer, the iOS changes completely overwrote the (previous) state on the mac, discarding the original local Mac contents, resulting in data loss and a questioning of my sanity.
I think the problem is not related to file content but to an incorrect evaluation of file time stamps.
In my case the problem is that files of any type (notes, Excel, Word) are overwritten when my mobile device connects after a longer period of absence.
The problem does not seem to be related to time zone differences. My devices are all in the same time zone. And even if the Obsidian server is in a different time zone, this would not explain why a file which is almost two weeks older replaces a file from a day ago.
Also, my files are not managed by any sync mechanism other than Obsidian’s.
Some speculation from my side as a former developer: At some point in Obsidian’s sync code a decision must be made to replace one file by another. Assuming Obsidian treats the file as opaqe, e.g., an MS Word file, then the decision would be based on the last modification time of the file as taken from the file stamp returned by the respective OS. If both client OSs are Macintosh, as in my case, a direct comparison of the time stamp values should never give an incorrect decision. I assume, therefore, that the comparison is against the time stamp of the server. If that server uses a different OS with a different representation of time stamps and the comparison is not based on a normalized time format, this might explain a lot of things going south. But as I said, this is only speculation.
Thanks, Cawlin. I have skimmed through the thread as suggested. But I got the impression that this is unrelated to my problem. The vault I’m using is shared with two other people. But overlapping use hardly exists because the other two users start Obsidian only infrequently. The sync problem with my iPad simply cannot be due to overlapping, i.e. conflicting, use.
However, I have now re-enabled restricted mode. I have two community plug-ins installed: Custom File Explorer sorting and Print. The former never worked stably across devices, and I tend to deinstall it. The latter is indispensable. I have to print some notes for meetings. I will, therefore, temporarily disable restricted mode for printing.
Still, I think the code around the sync decision – which file version to be propagated – should be inspected carefully again.
The sync problem with my iPad simply cannot be due to overlapping, i.e. conflicting, use.
Yes, that’s why I mentioned the thread — it’s about Sync acting like there is a conflict when there definitely isn’t one. Most of the examples discussed there don’t involve overwriting the whole file, but Sync’s apparent misunderstanding of dates/states seems similar in both cases.
I have noticed that this thread has been open since more than a year and a half. Since the severity of the bug is grave and since, as you say, the misunderstanding of dates/states is apparent, i.e. obvious, I wonder why this problem has not been solved already?
I only started using Obsidian a few days ago, but I paid for sync and immediately starting having the same issues as the others in this thread. I’m not running with any plugins at the moment, I’m not using any alternative sync methods - only the official paid one. I’m not storing anything in the icloud folder, it’s as default as it gets.
I set the conflict setting to “create conflict file” but this doesn’t seem to do anything - when there’s a conflict the ios version simply rejects the server version and uploads its own outdated version, overwriting it. I can of course revert to the actual most-recent version, that is if I notice and catch it, which can be difficult for canvases where the changes might be all over the place spatially.
It seems to follow a somewhat consistent pattern, though it only happens about half the time.
Modify a file on the windows program, wait for the sync icon to change to a green check.
Open the ios version and navigate to that file
Make a few small changes, wait for it to finish syncing, then close the app completely
Open the file again on PC, make sure it grabbed all the changes from ios (100% success rate so far)
Change the file on PC a second time, wait for sync to finish
Open on ios again - it should open directly to the file you were editing across devices as it was the last open
ios app rejects all changes and reverts back to its older version (see log screenshot)
This problem is so severe, it is resulting in lost work about 50% of the times I open the app in ios. It’s especially troubling because it is not creating conflict files, as far as I can tell. It’s simply rejecting the new versions of files and replacing them with outdated ones, even when no changes were made in the ios app, and even when the ios app has had time to fully sync. Since the severity and frequency of the issue are both so high, I think it’s unsafe to use the ios app at all at the moment, if you pay for the official sync service.
Has the dev team tried e.g. running the Jepsen tool to surface sync protocol problems in a systematic way?
Jepsen is a company and tool to analyze distributed protocols. They have broken multiple distributed DBs and published analyses about the exact failure modes. The tool is open source and they explain how to use it, I can imagine running it against a couple of Docker containers with the Obsidian CLI client installed, and given how easily people are finding sync problems in real life I’d guess it wouldn’t take long to find something.
I’m asking if the devs have tried it because I’m thinking of trying my hand at it. Though you know, I’m a paying client, not a dev. I’d hope that someone responsible for fixing the bug would do it.
I mentioned the Jepsen tool to find bugs. I looked into it myself and found that it’s a complex tool to test proper distributed databases. It’d be overkill for this.
The harness currently assumes that Sync is configured to create conflict files, and is pretty permissive: as long as all input text is saved in some note (including a Conflict file), the test is judged to pass.
And yet, even this fails reliably in Obsidian 1.12.17. Like, for this simple sequence with 2 containerized Linux nodes:
Disconnect node 2 from network
Create note A in node 1
Wait until it reports synced
Create note A in node 2
Connect it to the network
Wait until it reports synced
At this point, according to the Obsidian Docs, a conflict file should be created in node 2. But it doesn’t, leading to a data loss reproducible almost 100% of the repetitions.
Interestingly, the bug doesn’t appear if instead of actually disconnecting the container’s network one uses obsidian-cli sync:on/off to “disconnect” / “connect” again. But that’s not what a normal user does, of course; losing network connection is more similar to the situation of users on a phone.
The harness can do much more than this, and I have even further plans (like simulating slow / lossy network connections, simulating merged notes instead of conflict files, etc). But first I’d like to know if this looks useful already. Dev team, want to discuss? What would make this more useful to help fix Sync bugs?
In the meantime, I’ve moved my own vault to iCloud syncing.
