Device shows "Syncing (95%, 0 B)"


After upgrading to v1.18.0 (not sure that this is the cause) I see two connected devices with status “Syncing (95%, 0 B)”. I have seen this “bug” in the past and I resolved this by touching/rescanning the files that were out of sync.

This time it is different: if I click on “out of sync items” there is only an empty modal window. So I don’t know which files/folder are affected.

Any idea? Thanks!

In such cases sometimes --reset-deltas was helpful. Sometimes I have disconnected and reconnected suspicious folders, sometimes I have removed such folders from all devices and reconnected them. This is how I also dealt with cases like this when --reset-deltas couldn’t solve anything.

Now I only have the case that in a such window shows files that are definitely not on any device.

I have no clue why it happens and how to debug. You could go to the browser debugger and add a breakpoint in recalcCompletion in syncthingController.js to see if it thinks you need deletions or empty files/dirs/symlinks, however that info doesn’t help or lead to more options to debug.

If you can reproduce or can share details about when/under what circumstances it happens, that could help.

Device A: Folder is “send only”
Device B: Folder is “receive only” - this device is where bug happens

In console log there are entries with “recalcCompletion”: the object has “needItems: 3” - where can I see which files are needed?

None are actually needed if opening the dialog with the list of out of sync items is empty. There’s apparently been a bug in the metadata accounting. Unless you know exactly when/how it happened, it’s not possible to get more info now, after the fact. You can run with --debug-db-recheck-interval=1s to trigger a recalculation. Do restart syncthing once all folders are up and running to prevent a recalculation every time a folder restarts.

In my experience, Syncthing doesn’t handle renames when only the case is changed. When I get the 95% / 99% error, I can always see (by comparing SO to RO) that either the path / directory or file was renamed by case on the sending end.

Since St must know there is a difference (and often the devices won’t show the files)…


… why not error trap it and tell it to delete the RO affected path / directories / files and simply redownload them (could be an option to select, e.g., “clear and redownload full path due to receive errors”.)

If the changes are small, eg, a folder rename, I will manually do that, rescan and the error will clear, but I have also deleted full directories to resync.

Just offering suggestions!!

On my end it’s not about missing solutions, but knowing what the problem is. In all situation presented yet, there hasn’t been any clear cause as you suggest here (case difference) - we were just looking at an inconsistent state after the fact. If you have a case with a concrete potential cause, lets debug that and try to get to the bottom (or even better if you can reproduce, please share the steps).

1 Like

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