I have a one-way sync set up with a Mac (send-only) and Windows (receive-only). The Mac is showing 11,145 “out of sync” items for the PC, but looking at the PC shows it’s up to date (it has all the files locally).
Clicking on the list gives me a list of items that don’t even exist on the Mac! I confirmed this on Finder and Terminal. How do I get rid of this? It’s annoying to see it stuck at “syncing 93%” waiting for the PC to sync 11k files that it doesn’t want/need and doesn’t even exist!
You may experience a bug fixed in the upcoming v1.4.0 release. You can install the RC to test or wait for the release (beginning of next month).
Can I install the RC on the Mac only and keep the PC on release? Or I need to keep both on the same version? I just started using this yesterday so I’m not sure if that would work.
It’s the windows side with the bug (it didn’t send the full info to the mac, thus the mac reports an incorrect status for windows). All assuming it is that bug.
I updated both of them to v1.4.0-rc.5 and not only did it not solve the problem, it actually made it worse. Now the out of sync list shows 79,279 items which already exists on the PC. Not sure if the the previous “non-existing” items are still there (mixed in with the existing, already synced, but still listed as unsynced items) since there’s no way I’ll dig through the list of 8k pages / 80k items. Maybe I should’ve just left he 11k out of sync items alone. >_<’
I completely missed the elephant in the room (in your screenshots): You are sharing between mac (case-special - don’t remember what exactly the characteristics are but not “just” insensitive if I remember correctly) and windows (case-insensitive). For the out-of-sync items (well one of them), check the path on both sides for any differences in case only. If there are paths which are equal except for their case, that’s confusing Syncthing. Best thing is probably removing the folders in Syncthing, making sure the casing is the same on both sides and readding.
No. It’s a “Mac OS Extended (Journaled)”. The case sensitive format is “Mac OS Extended (Case-sensitive, Journaled)” - but very few people use that coz it’s more trouble than it’s worth. So the Mac and PC are case-insensitive on both ends.
Already checked the path (for both) and there’s nothing out of the ordinary. Also rebooted both machines a bunch of times (pre and post upgrade).
Anything else I can check (other than removing and re-transferring 80gb worth of data)? It looks like Mac is expecting Windows to download the files when it already has them. That’s why it’s showing “up to date” on the PC, but somehow the Mac isn’t aware of it.
Strangely enough, I have 2 other synced folders between the 2 machines (so same OS and filesystem involved) but it doesn’t have a problem with those 2.
Looking at the Syncthing UI on the Windows machine itself, do the local folders think they’re up to date, or do they have out-of-sync items that correlate with the ‘Remote Devices’ view of the Windows machine from the Mac Syncthing UI?
It’s all up to date. It has exactly the same number of files, folders, and size for the global and local. (Like in the first screenshot)
Do you have any Ignore Patterns set up on either side?
Yes. Exact same patterns for both. But I fail to see how this question is relevant when, like I mentioned previously, “the out of sync list shows 79,279 items which already exists on the PC”.
Whilst I bow to the expertise of others on this site, I’m convinced there’s something screwy about the completion state reporting of Remote Devices - and I suspect that’s what you’re seeing here.
If the PC’s view of its local folders says it’s Up to Date, but the Mac’s view of the PC as a Remote Device is different, then I suspect you don’t have anything amiss - just that the reporting is bad.
I’ve raised this before - Remote Device Sync Completion State - but I’ve not been able to find a reproducible test case yet. If this is what you’re seeing, then it’s good to know I’m not alone… 
I mistakenly thought the repair mechanism in 1.4.0 will kick in anyway, but it doesn’t if the bug that’s fixes is in the past (which is the case for you likely). To check this you can download the stindex tool from here: https://build.syncthing.net/buildConfiguration/Syncthing_Tools/55196?buildTab=artifacts&focusLine=0 (click login as guest, then under windows amd64 you find stindex.exe). Then run cmd or powershell to execute it while Syncthing is not running like stindex.exe -mode idxck. If there’s no output I was wrong, if there is output you need to remove and readd the affected folder on windows (no retransfer, but full rehash). Or you wait as I will bring up potentially adding a check and db repair mechanism for this.
@Moisie There’s comfort in knowing that. I hope it gets sorted out soon.
@imsodin Can’t run the file, Windows says it’s unsupported for 64-bit. Looks like the wrong file got uploaded on the windows_amd64 folder. I downloaded and hashed both the 386 & amd64 files to double-check and they’re exactly the same file.
Die you try “Ignore Permissions” regarding the affected folders?
No. I thought it’s only for FAT? I’ll try it now. Hopefully, that’ll do it.
@Mike You can grab stindex here, alternatively. https://forum.syncthing.net/uploads/short-url/5PN4M9j6ZoihZSnzKKzhwcqEAYS.exe
EDIT: Uhhh, this looks strange with the cryptic filename. Here’s the source: Fresh setup with 2 devices, sync stuck with no progress
@Andy It didn’t do anything.
@Catfriend1 Thanks a lot for that! This one worked.
@imsodin I got this outupt:
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
Missing need entry for needed file "<redacted>", folder "<redacted>"
4 block list entries out of 96278 needs GC
What exactly should I do regarding “remove and readd the affected folder on windows (no retransfer, but full rehash)”? I just move the affected folders somewhere on the PC first, move them back, then rescan?
Its not only for FAT, is not a fully explanation and so a little unclear:
This means deleting the peer on both sides (not the files or directories or any moving). Then exactly match the directories to the peers and how they should be (for example with a tool like FreeFileSync) and then reconnect the peers.
I sometimes do this too, because the indexing has its limits with regard to repairs, etc. In any case, it creates a new starting point and then it should at least be good for the next time. You should do this with all peers that don’t work properly.
With regard to the “Ignore Perms” I have basically activated them on my Linux servers. Not on Windows computers. Sometimes it helped to deactivate the “Ignore Perms” and to reactivate them after the peer scan was done, so I have been able to fix a lot of errors. However not always, at the latest then I proceed as described above.