-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always syncing 95% for encrypted devices and removed files #8914
Comments
For what it's worth, I'm unable to reproduce that while playing around with a triangle formation T1/T2/U and creating/deleting files. Some logs, some |
I see that there is strange device |
Here is |
Thanks, interesting. The deleted files look like they were deleted "concurrently" on several (>1) devices, yielding several different "versions" of the deleted file. These are of course equivalent and this doesn't matter, except that all devices should ideally agree on which version is the latest, for completion purposes. The untrusted device doesn't get all the info the others have though, so its view of which deleted file is the latest can differ, and then it looks out of sync. I'll need to ponder this. (77777 is the "local device" in the database) |
@calmh Interesting. Well, I did the following:
It looks like deletion may not be correctly processed if state is propagated through untrusted device. |
Oh I think this might be an artifact of a fundamental issue with our "hiding" of the version vector on untrusted devices (we basically erase it). There are certain conditions where conflicts get stuck - which sounds a lot like what you describe. Last time I looked into it I didn't find any solution on the untrusted side - as far as I remember I pondered changing the general conflict resolution: Currently the losing side does that, the other side does nothing. The idea was to do conflict resolution everywhere. I do not remember if that idea was flawed or if I just didn't follow through. I'll see if I can find any record of that tomorrow. |
Any advice on how to fix this? Getting the same issue with an untrusted device? |
Still having this issue on version 1.27.4. Also, I think my previous comment has an error; my 2 devices are set up as trusted, not untrusted. |
I think I may have similar issue here: #9482 |
Environment
Version: v1.23.4, Linux (64-bit Intel/AMD)
Configuration: three devices and one of devices is encrypted (i.e. untrusted).
Problem
Syncthing almost always shows state
Syncing (95%, 0B)
when one of peers is untrusted device (and encryption is enabled). I have never seen such problem between two trusted devices. Usually syncthing says that one item is out of sync and as I can see it is deleted file. Restarting/rescanning folders does not help at all, but sometimes probably after more changes are synchronized between devices, a set of unsynchronized files may be changed (there can be more than 1 item and they may be other files, i.e. state is changed periodically). I suppose that the third device forces resync sometimes.The interesting thing I noticed latest time was that untrusted device showed that file had been modified by "Unknown" device (Mod. Device column) while trusted peer said that file had been modified by third device (trusted). I tend to think that to reproduce this issue three devices are needed. Let them be:
All of devices share the same folder, all of devices are paired to each other and set up to synchronize in both directions:
i.e. changes from T1 to T2 may be propagated directly or through U.
I believe that there may be some kind of race condition in propagation of deletions so that the problems happens not for all deleted files. Suppose I delete some file on device T1. T1 propagates deletion to both T2 and U device. After that T2 propagates deletion to U. At this point of time U receives two simultaneous deletions from T1 and T2 and probable handles it incorrectly. And bad state persists until more changes from T1 are received. While T1 is turned off, T2 and U always show Syncing 95% both.
The text was updated successfully, but these errors were encountered: