Non-existing files stuck on "Out of Sync Items"

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… :wink:

1 Like

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.

stindex

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

1 Like

@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.

Don’t reset anything!
As I wrote above my theory is, that there’s a problem with sequences however:

There’s nothing about sequences there. So please hang tight, I’ll come up with the next thing to test.

@Moisie We know there’s something screwy: Crash or hard shutdown can case database inconsistency, out of sync · Issue #6335 · syncthing/syncthing · GitHub and Syncing issues, database missing sequence entries · Issue #6304 · syncthing/syncthing · GitHub and Jakob recently discovered why, so there’s something fixes in 1.4.0 (maybe there’s still more screwyness, but until proven otherwise I assume not :slight_smile: ).

Regarding permissions: That’s definitely not the issue here. Permission errors would result in out-of-sync/failed items on the folder. This is just about remote devices.

Thanks for the heads up, I’ll have a look what’s going on there.

1 Like

Another thing I noticed: You write about send-/receive-only, but the folder type in the screenshots isn’t actually send-/receive-only, they are both send-receive. Did you change that recently or do you just mean that things don’t change on one side but folders have always been send-receive?

And try running with -reset-deltas command line option on both sides to see if that changes anything (that will retransmit metadata, no actual data).

1 Like

That’s now fixed, the latest build should have the correct binaries (https://build.syncthing.net/buildConfiguration/Syncthing_Tools/55201?buildTab=artifacts).

@calmh The build script for the tools job didn’t actually set GOOS/GOARCH. I excluded a few platforms that didn’t build by trial and error.

They’re still send-/receive-only, I haven’t changed that. It’s actually shown on the first screenshot. Maybe you got confused with the 2nd screenshot - that’s just the sever details, no folder details (to illustrate each machine’s state and how they see each other).

This did the trick! Thanks a lot for the support and patience, it’s working great now.

I wish there’s a way to tag your post as the solution. So that people with similar issues can quickly find it.

1 Like

Right, I did.

That’s nice to hear!
(And a bit weird, as on upgrade the same thing happens as if you run with -reset-deltas.)

In which way I can use such commands, with PuTTY or inside of Syncthing?

You pass it as an argument when you run Syncthing so it’s either you do it on the terminal/shell (if you’re doing it locally) or ssh/putty (if you’re accessing remotely) or via the GUI (if you’re using a wrapper). Make sure to put it on both ends! And you just need to use it once.

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