Identical folders appearing in "Out of sync" items, wont seem to finish syncing

Hi, I have music folders shared on 2 different machines, lenneth and lezard, that have some conflicting messages from syncthing.

From the web interface, under the folders list of both lenneth and lezard, they are listed as Up to Date.

However on the Remote devices -> Out of Sync items of lenneth only (and not on lezard), the following items appear:

“Cal Newport” Mod Time 2018-08-05 12:52:00 Mod Device lezard

“Cal Newport/2016 - Deep Work - Rules for Focused Successs in a Distracted World” Mod Time 2018-08-05 12:32:26 Mod Device lezard

However, these cannot be accurate because the ls output on each folder is:

from lezard:

madumlao@lezard ~ $ ls -ld  Music/Cal\ Newport Music/Cal\ Newport/2016\ -\ Deep\ Work\ -\ Rules\ for\ Focused\ Success\ in\ a\ Distracted\ World
drwxrwxr-x 3 madumlao madumlao 4096 Nov 28 02:39 'Music/Cal Newport'
drwxr-xr-x 2 madumlao madumlao 4096 Nov 28 02:39 'Music/Cal Newport/2016 - Deep Work - Rules for Focused Success in a Distracted World'

from lenneth:

madumlao@lenneth ~ $ ls -ld Music/Cal\ Newport Music/Cal\ Newport/2016\ -\ Deep\ Work\ -\ Rules\ for\ Focused\ Success\ in\ a\ Distracted\ World
drwxrwxr-x 3 madumlao madumlao 4096 Nov 28 02:10 'Music/Cal Newport'
drwxr-xr-x 2 madumlao madumlao 4096 Nov 28 02:10 'Music/Cal Newport/2016 - Deep Work - Rules for Focused Success in a Distracted World'

It should be noted that except for mtime, the folders and their contents are 100% identical. There are no stignore rules that would apply to those files as well.

No combination of rescan, restart, touch and rescan, and restart, of both nodes seems to make this “Out of sync” item go away.

It should also be noted that lenneth has occasionally force powered off due to overheating, so I’m suspecting that some temp cache file in one or the other laptop needs to be cleaned.

By the way, there are no .syncthing.*.tmp files on the share of either machine:

madumlao@lenneth ~/Music $ find -iname '*.sync*'
madumlao@lenneth ~/Music $
madumlao@lezard ~/Music $ find -iname '*.sync*'
madumlao@lezard ~/Music $

Seems like a missed index update. This could have happened in earlier versions where there was a bug related to this.

Try stopping syncthing on both sides, running syncthing -reset-delta (or deltas, can’t remember) on both sides, and start it back up.

Ok I’m pretty sure I ran reset-deltas already that one time, but I’ll try it again just to be sure.

Try on both sides.

I just reran it on both sides, the problem still persists.

Is there anything I can force on one side to make it believe that the folders are synced? Are there any caches or something that I can clear?

Did you check that the folder case is the same on both sides?

Yes, they are both in the exact same case (it’s a linux filesystem).

You can probably reset the database on both sides or remove the folder on both sides and re-set it up.

What does resetting the database imply in terms of processing time? I have over 200 gigs of stuff on both sides over non-SSD disks. It should basically be equivalent to doing an rsync from one to the other, except that it outputs syncthing indexes, right?

Also is it possible to reset the db but only for the affected shares? Every other share (160+GB) seems to be fine.

Removing and readding a folder (share) is the same as resetting the database, just for that folder alone. It is not equivalent to rsyncing, as it will have to hash all files (instead of just comparing size and mtime). So I’d readd the folder. If you don’t want to set its options again, you can copy the config file, then start syncthing, remove the folder and stop syncthing and put your copy back in place.

I have so many problems with out of sync folders, i really wished there was a button for: reset database, reset deltas, remove and re-add folder. Or even better: seperate index for each folder, able to reset the folder-based database with a simple click <3.

Removing and re-adding seemed to work, but the time cost is prohibitive. It was about a couple hours, not to mention that my CPU usage was high during the duration. I just left it overnight, but I wonder if there should be an easier way.

As I suggested in another topic, Is there any way to force a particular share / file to be authoritative? I would very much appreciate if there was a way for the user to mark some file as the authoritative version. Even if technically “touch”-ing the file does the exact same thing, it’s only by proxy and we have to wait for the differencer to pick it up, and in this case it fails to.

Just to chip in, I was looking on the forum for similar symptoms as mine, and this fits pretty well:

  • 4 nodes (A, B, C, D), each of them on v0.14.52
  • 3 Linux nodes (B Debian Stretch, C and D Ubuntu 16.04 LTS), one Windows 10.
  • The shared folder in question has 16750 files, 4190 directories for 7.39 GiB with a certain number of ignore patterns (that have changed over time).
  • All nodes seem synced (from file count and size perspective, as well as status in the “Folder” column)
  • in the “Remote Devices” column, only node C claims that node B is Syncing 820 items (992 MiB) for many weeks already (numbers fluctuate actually, as more files are added).
  • All other nodes see the other nodes are synced in the remote devices column.

Since this is not critical for now (files do seem to be synced), I did not try too many actions yet. Will wait until scheduled maintenance next week before trying to remove and re-add the folder.

But this bug does seem to happen to more than one people.

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