I’m running v2.0.10 on my local Ubuntu machine (k, device ID starting with V) and on an untrusted Ubuntu remote (b, device ID starting with 6). I’ve run syncthing debug reset-database on both, and restarted the service.
The problem is that synchronization is stuck at 99% as usual, on a bunch of files that were modified by a device ID that’s not among my devices. I have two Android devices (S running the fork, v2.0.9) and an old Pixelbook that I haven’t booted in a month and is badly out of sync), but neither has the ID shown under the “Mod. Device” column.
The local machine k and the Android S are in “Up To Date” in each other’s UIs. On the Android, the UI shows the same 73.5MB being out of sync with the untrusted remote b.
UPDATE: On the Android (S), I used the Syncthing Fork option to reset the database and the deltas, and now the nonexistent device identifier VXIL44W is gone from the Out of Sync Items. Is it possible that Syncthing Fork keeps transmitting old data from devices removed from the pool, and that blocks the sync?
Still the sync continues to be stuck. There other Out of Sync Items appear all modified by S. Trying to get this unstuck, I stopped Syncthing Fork on the Android, reset again the database for my Ubuntu machine k and the untrusted remote b, and let them sync. An hour later, the sync has been stuck at ~62% (60% on the remote), with all Out of Sync files haing “Mod. Device” set to S. This seems buggy - why wouldn’t the two Ubuntu instances sync if the Android is unreachable?
Forgot to mention and can’t edit the post: the Android device modified less than 10 files out of the “Out of Sync Items 7,539 items, ~4.11 GiB” erroneously shown in the Web UI on my local machine k.
In the meantime I recreated the untrusted “Receive encrypted” remote folder on b while k and S were online, and the sync finally completed on all 3 devices in the cluster.
I don’t consider this a solution. Seems like there’s a bug in synchronizing encrypted remotes with more than one machine (I’ve seen this before but haven’t posted about it): when a device comes back online with a database containing modification device ids that are no longer in the cluster, the sync gets stuck. @calmh does this sound plausible?
Next, I booted that old Pixelbook and it again led to the sync apparently getting stuck (stable numbers of files over 5+ minutes), with files modified by that nonexistent VXIL44W device. Perhaps the protocol can’t distinguish between a device removed from the cluster and one that hasn’t ever come back online, or perhaps I haven’t explicitly removed the device from the UI but rather installed a new OS on it. What’s perverse is that the sync is broken (stuck) between my machine k and the remote b, not between the Pixelbook and other machines. This is the part that seems buggy to me.
Bringing back online the old Pixelbook (after upgrading its Syncthing to v2.0.10 and running reset-database), also restored filed I had deleted yesterday from my machine k, brought over old names of files I had renamed, and generated a ton of .sync-conflict files. Is that intended?
Then the 4-way sync eventually almost completed, with the encrypted remote believing that 9 random files were incorrectly modified by the S Android or the Pixelbook.
