At a guess, you might have files on the two devices that differ only in case (document vs Document). This results in really odd things, like what you’re seeing. It’s a bug, unfortunately one that’s tricky to solve.
On Android, in the Syncthing app there’s a “reset db” option under “troubleshooting”
Stop all instances of Syncthing on network
Delete all index db files on all devices (rm * inside the index-db folder)
Restart Syncthing on all devices
I started by running Syncthing on the laptop I was having issue with first, too - since it had all the new files that weren’t being synced. I am not sure if this made a difference, but I thought it might be worth mentioning.
Hope I don’t run into these issues again, but at least Syncthing is pretty friendly about rebuilding its indexes after being manually deleted.
The first command that enables case sensitivity recursively doesn’t enable it for the folder it’s run from, so it’s necessary to run the first command and then change to the parent directory and run the command for the single folder on the folder you were just in.
Hopefully now I won’t see any of these case sensitivity mismatch errors anymore.
Just to prevent any misunderstandings by people reading this:
The upgrade to 1.4.0 does not require a database reset.
Resetting the database should never be done lightly - create a thread on the forums discussing your problems and the way forward first. @averyfreeman did their due diligence first and found a solution that worked and that’s great. With lesser care you might just create more problems instead.
Migrating the database requires reading and re-writing every file entry, and in some cases this turns up pre-existing corruption. We’ve put a fair amount of thought into repairing and fixing such corruption when encountered, but sometimes there are cases we didn’t anticipate.
There’s tens of thousands of users on 1.4.0 and a handful of known migration failures so far.
I don’t think this issue had anything with the migration to do.
It wasn’t meant to be like that. Of course the reader have to know the story you both know about it in my cases. I did not mean that this is generally necessary. As you know, there were things that I couldn’t fix with the available tools, maybe I have Synologys or because of others reasons.
That is why I also expressly say here that anyone who changes from <v1.4.0 to v1.4.x does not have to do anything if all processes are running.
Yes, thankfully I only have ~10GB of synchronized data. I couldn’t imagine doing it with far more than that - I think I read one thread where re-creating the db (rescanning all the files from scratch) would take upwards of 10 hours, so not everyone will think this solution is all that ‘easy’.