One side showing Syncing even when Perfectly Synced

[PeterR-SK]

Hi,

I’m starting to experimenting with Syncthing and experienced below issue.

Computer A = “Comp-izba”, Windows 10, Syncthing 1.14.0

Computer B = “Comp-obyvacka”, Windows 10, Syncthing 1.14.0

Computer A is showing:

Computer B is showing:

• Folders are perfectly Synced although computer B is saying they are still syncing.
• Both folders are Send & Receive, no file versioning, no ignore patterns. Although this was not initial setup, details below.
• Folder contains very large files, some over 6-7 GiB. Maybe this is relevant.
• There were no power outages, RAM or other HW issues.
• On both sides, Syncthing service was shutdown and started and even entire computer restarted multiple times.

Are folders really synced?

Yes, they are. Initially Computer A had more data and I wanted to use Syncthing to sync missing data to Computer B. Initially I shared “Trainings” folder on Computer A as Send Only. When prompted on Computer B, I left default share setting (Send & Receive), but changed versioning to Trash Can File Versioning. At that point it started to sync, although both computers were showing different amount to be synced on right side. Maybe should I had give Computer A more time to calculate the folder before I accepted the prompt and created the share on computer B?

When it synced I think left side changed to Up to Date but both sides were still showing Syncing status on right side which was stuck. Sorry didn’t make screenshot at that time. At this point it was strange and I think I even did Rescan all, but it didn’t change anything. Then I decided to change Computer A share type to Send & Receive - it immediately changed the status of remote device on right side to Up to Date.

So Computer A was fixed and as expected, but Computer B is stuck. I changed File versioning to No File Versioning - no help.

So I checked amount of data, number of folders and files is exactly same on both sides. I though noticed that although Modify time on files is the same, Creation time is not. So I used Windows command utility Robocopy with /MIR and few other parameters to mirror source to destination. It reported files as modified in source, but didn’t copy any (skipped all folders and files). It did make sense, because if modification time is the same, there is no reason to copy anything over. However, there is also /TIMFIX parameter, which will change timestamps, and apparently also creation time timestamps. So I tried with /TIMFIX and now even creation timestamp as well as modify timestamp are the same. Even another attempt with /MIR now says that all files are the same.

So indeed, if Robocopy says files are same (in sync), they must be.

Anything else I was concerned about?

Yes, permissions. I initially tested SyncThing with elevated permissions, and on computer B even with different user account. On computer B I later changed the user under which Syncthing is running, so I had to shutdown Syncthing and move its data in C:\Users\original_user\AppData\Local\Syncthing to C:\Users\current_user\AppData\Local\Syncthing . Also moved the Sync folder of Default Folder to new location and changed its location in Advanced Configuration, but this is not relevant I assume.

I am now running Syncthing in Task Scheduler as per User Guide on user logon. Although in reality Syncthing synced the folders, I was concerned user under which scheduled task is running don’t have permissions to the folder. Indeed, that user didn’t have permissions, but Authenticated Users group did have Modify, so the user had effective permissions. Anyway I added also the user to permissions with Full Control, but no help.

I have User Account Control (UAC) enabled on both computers so I also changed the scheduled task to run with elevated permissions (user under which it is running is admin but will not use admin privilleges until you tell it to use elevated privilleges), this didn’t help either.

So what now?

Folders are synced, permissions are good. I don’t see anything suspicious in logs, both computers are on same subnet. I know I could probably start from scratch or reset the DB, but would be good if there is other mean to resolve this. Maybe there is something on my end that I did not consider yet. I noticed few more people reporting this kind of issue, but there is always some other variable, so I decided to open new topic.

Do I have any idea what I can try? Or any more information I could provide to help?

Thanks.

[imsodin (Simon)]

@PeterR-SK

At that point it started to sync, although both computers were showing different amount to be synced on right side. Maybe should I had give Computer A more time to calculate the folder before I accepted the prompt and created the share on computer B?

During a large synchronisation it is expected that you get differing and chaning sync completeness. All Syncthing devices are independent: They show you what they think about themselves and about others compared to what they know as the global state. All of those are changing when multiple devices first connect and exchange metadata. Whether you immediately connect or not might have an impact on performance, but it should work either way.

@PeterR-SK

I though noticed that although Modify time on files is the same, Creation time is not.

Syncthing doesn’t care about creation time - as long as modification time matches, all is good.

There isn’t any info on the items that are shown as out-of-sync (or I missed it). Is there anything special in those files compared to the ones not reported, or any pattern?

If it’s a simple thing for you, additional info to provide would be the output of the /rest/db/file endpoint for one of the affected files: GET /rest/db/file — Syncthing documentation
However don’t bother if it’s inconvenient, I expect to see “the usual”. I.e. a confirmation that everything is in sync, just that device B isn’t aware that A is indeed in sync. How that occurred isn’t visible in that information unfortunately.
What you can then try to resolve it without a db reset is to run Syncthing with the -reset-deltas command line flag set on device B to re-exchange all metadata.

[PeterR-SK]

Hello Simon,

thank you very much for your quick response.

@imsodin

There isn’t any info on the items that are shown as out-of-sync (or I missed it). Is there anything special in those files compared to the ones not reported, or any pattern?

I think computer B is showing all items that it initially synced successfully as Out of Sync. These are the files and folders that were initially missing on Computer B. This is only obvious pattern I see. Files are big and some folders and files do have long names and spaces in them. One file I found has comma “,” character in name, I didn’t see other special/unicode characters.

List of Syncthing believed Out of Sync Items is populated:

@imsodin

If it’s a simple thing for you, additional info to provide would be the output of the /rest/db/file endpoint for one of the affected files: GET /rest/db/file — Syncthing v1 documentation

Well, this took me some time, but thanks to you I learned something new and managed to perform my first ever REST API call :). Attached are outputs from both sides. There is slight difference, but probably not relevant.

rest_db_file_comp_izba.xml (1.2 KB)

rest_db_file_comp_obyvacka.xml (1.1 KB)

@imsodin

What you can then try to resolve it without a db reset is to run Syncthing with the -reset-deltas command line flag set on device B to re-exchange all metadata.

I did this as well, started scheduled task with -no-console -no-browser -reset-deltas and indeed, for split second it was showing Syncing and then turned into Up to Date on Computer B. Removed -reset-deltas now. Still showing Up to Date after restart.

Is there possibly some issue with metadata exchange?

Peter

[imsodin (Simon)]

Both the rest api output (it’s json, not xml ) and that -reset-delta resolved the issue show that it is indeed a “known” problem: Some indexes (metadata) were missing. Unfortunately I still have no clue why.

Thanks for the report!

[PeterR-SK]

Good luck with figuring that out. If there is any way I could help with non-developer perspective, just let me know. Maybe I will try to delete synced data, reinstall Syncthing from scratch (deleting database and config) on both computers and see if I can reliably reproduce the issue.

[terry]

@imsodin

Some indexes (metadata) were missing. Unfortunately I still have no clue why.

I don’t know if it helps or is relevant, but when it happens, I can usually trace it back to a renaming event, eg, the directory name is changed, or the files get capitalised for readability.

I wonder if the metadata sees the data in it original form, but somehow when presented with a case change, it’s ignored rather than being updated as it thinks the names are the same. The reset delta simply clears the differences.

I don’t recall St being out of sync so often before case insensitivity was introduced.

…or I could be totally wrong