Dealing with Out of Sync Items error on Encrypted Folders

Greetings friends!

First, a big thank you to everyone involved in this awesome project.

Running some tests to migrate into an all encrypted “cloud” Syncthing setup.

Is there a way to deal with “Out of Sync Items” on the new Encrypted Folders?

Those pesky MacOS “.DS_Store” files seem to always find a way to create sync conflicts.

Encrypted side:

MacOS side:

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?

I’d generally advice to ignore them: Ignoring Files — Syncthing v1 documentation
Though they still shouldn’t produce any problems like you see if not ignored.

Where are those screenshots from and how do you know that the enc. file path corresponds to .DS_Store?

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.

Current test setup:

Android1 <–> Encrypted Syncthing (Docker) <–> MacOS (MacbookPro)

@imsodin Any way to diagnose this further? I read about “syncthing decrypt” command but would it also work for deleted files (0 byte, file not exist)?

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.

You might be seeing some variant of Device tries to push ignored files to a remote device in a 3-device setup · Issue #7474 · syncthing/syncthing · GitHub, i.e. ignored files not propagating properly. I need to understand the entire context (above question) to say with more certainty.

1 Like

@imsodin Oh, understood! On the new Syncthing device using encrypted folders:

Clicking the “1 Items, ~0B” link (red box) in front of “Out of Sync Items” is what produces the information below:

On MacOS device side:

Clicking the “1 Items, ~12 KiB” link (red box) in front of “Out of Sync Items” line is what produces the information below:

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).

GET /rest/db/file produced no information to compare to.

<a href="/rest/db/file?folder=android_folder1&amp;file=6.syncthing-enc/T5/MRB7U6ADHGJF7GTSK6IN5UF7I584U3VL3J271">Moved Permanently</a>.

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.

The command needs to be pointed at your Syncthing api/web UI listening address, there’s an example here: REST API — Syncthing v1 documentation

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