It is likely due to a .DS_Store deletion followed by a quick recreation of the file.
I’ve tried waiting a long time in case a self-heal would occour, touching and deleting .DS_Store file on the MacOS side, adding it to .stignore, but no success.
Since there is no such “6.syncthing-enc/T5/MRB7U6ADHGJF7GTSK6IN5UF7I584U3VL3J271” file on the Encryped side, haven’t touched anything there.
Any ideas how to get rid of this Out of Sync Error?
Maybe it could be good to have in the .stignore the entrance (?d).DS_Store or (?d)(?i).DS_Store in case you have .DS_Store and .ds_store as filename. I think there are some tests needed. Explanation:
// (?d) Prefix indicating that the file can be deleted if it prevents the folder from being removed
// (?i) Prefix indicating that the pattern should match regardless of case
Interesting. This is my third iteration with encrypted folders starting from scratch, with the first two attempts using .stignore without success.
Mainly .DS_Store files already present on other devices (Android1) would display “Syncing (95%, 0B)” forever with “.DS_Store” ignored on MacOS end.
I ended up removing .stignore files and deleting all .DS_Store I could find and starting fresh again, and here we are, my best result so far with just this one conflict.
Top screenshot is from media folder (with pictures and videos) on new Syncthing device with encrypted folders, bottom is from same folder on MacOS machine.
Did try the .stignore files with “(?d).DS_Store” inside, but such files already present on other devices (Android1 in this case) would display “Syncing (95%, 0B)” for many many files.
Not sure this is expected behaviour. Makes sense since the only other syncthing Android1 is interacting with knows nothing about filenames because its using encrypted folders.
I did not want to have to find and delete them manually on Android1 phone so I removed all .stignore files, let them sync, deleted every file I could find, and started again from scratch. This time I only have (or still have) this one conflict.
I was more asking about where the screenshot excerpt is from, e.g. are we taking remote devices showing as “syncing”, or folders as “out-of-date”? Full UI screenshots to get an overview would help.
Hmm ok so fully connected setup (mac is also connected to android), that means it’s not #7474.
You could get metadata on the out-of-sync file on both mac and server1 through GET /rest/db/file — Syncthing v1 documentation. Or try running with --reset-delta on either and see if that gets rid of the problem.
@imsodin Sorry if not clear. Disregard Android2, current test setup is: MacOS (MacBookPro) <–> Encypted folder (SyncServer1) <–> Android1, so mac and android do not connect directly, only through SyncServer1.
Right my bad, messed up android 1 and 2. Still, #7474 would mean that the enc devices shows mac as out of sync, but mac should show server 1 as up-to-date. My suggestions above still stand, though they are complete shots in the dark, no promises that either will yield results.
Disregard the following, it’s basically a note to myself (theory that turned out to be wrong but still possibly relevant in another context):
Assuming two devices A and B initially have the same file foo, scan them and thus are conflicts with versions {A: 1} and {B: 1}. The encrypted device U in the middle just sees version {1: 1} from both. If U gets {A: 1} first, it passes that on to B, which will resolve the conflict and everyone ends up with {A: 1}. Now if U first gets {B: 1}, it passes on {B: 1} to A. But A won’t resolve the conflict, because {A: 1} comes before {B: 1}. So A has {A: 1}, U has {1: 1} and B has {B: 1}, B and U consider each other mutually in sync, A considers U as out-of-sync and U should consider A as up-to-date. Damn, not the same symptoms as presented here. Still I think conflict resolution might be broken with the current “encrypted version scheme” we are using.
@imsodin Didn’t get very far here. Looks like there is no “–reset-deltas” for MacOS and couldn’t run it in the Syncthing Docker container either (syncthing can’t be running, and if I stop or kill it the container restarts).
No worries, its just a test setup. I’m having some weird network error on top of this (only with ANDROID1), so its probably time to pull the plug. If troubleshooting further helps, let me know.
It does exist regardless of operating system, what makes you think it doesn’t? And on docker you should be able to use --entrypoint to override the command that’s run.
