Conflict Resolver reports file as "Modified By" wrong peer

Thank you Audrius, will do asap

Hi again,

since Syncthing’s information on PC “A” and “B” is very inconsistent (as described above), presumably hardly explainable even with screenshots, and finally probably not easily solvable, I guess I will have to re-synchronize anyway.

The master folder with ~50.000 files is on PC “A” whereas on PC “B” exactly 15 files were changed recently.

If now I remove the synchronization on both PCs (but keep the folders at both ends) and create a new one from scratch, will the 15 additional files on PC “B” be deleted, or will they be reported as “Locally Changed Items”?

Thanks very much :o

They will probably end up as conflicts, but I’d back them up just in case.

1 Like

Thank you.

So what I do is this?

  1. Remove the folders on both ends from Syncthing
  2. Keep the (slightly differing) ‘physical’ folders at both ends
  3. Back up the modified files
  4. Add the existing folder on master PC A as “Send Only” to Syncthing
  5. Add the folder’s ID on slave PC B in Syncthing, point Syncthing to the existing folder

Then Syncthing will hash all files at both ends and tell me about the ones that have different hashes (which should be my 15 changed files on PC B).

Is that about correct…?

That’s the idea.

1 Like

Thank you.

Couldn’t determine this on the Understanding Synchronization page:

When a file has the same hash but a different name (or different timestamp) on different devices, how is this handled?

– Edit: I believe that this is at least a part of the problem that I’ve been describing

Different files is a different file, it’s not handled any way specially.

Sure – but what’s the definition of ‘different’, for Syncthing?

Is a file with the same hash but a different date ‘different’?

What about two seconds difference?

What if a file is ONLY renamed?

Is there a definition somewhere be read?


Files are identified by their path, if the paths are different the files are not even considered for equality, as they are at different paths.

For two files at the same path they are different if their mtimes, sizes, permissions, version vectors (which is an internal version tracking thing) are different.

1 Like

Phew – it sounds difficult to me now for files to be stably noted as identical by Syncthing.

Don’t these many conditions for identity lead to problems like the one I’m having in the OP?

It seems that:

These files definitely haven’t been touched on PC “A”.

Is not true, hence why conflicts were generated.

But this definitely happened today again.

I worked until 5 pm on a file on PC “B”, and afterwards the file got reported in Conflict Resolver on PC “B” as changed at 5pm today by PC “A” – where I hadn’t even touched PC “A”!

I guess you can compare the files.

Sure. The file I’ve been working on at PC B is from today (and much larger), the one on PC A is a couple days older, and smaller.

Conflict Resolver tells me that the younger and larger file was modified by PC A…

There is no conflict resolver in syncthing. Syncthing just moves the files around without asking.

The fact itself that the conflict happened implies that the file was modified, even if its metadata differences.

Guys, sorry I don’t understand this.

With the completely new synchronization set up as described above at post #6:

How is it possible that PC ‘B’ shows the synced folder as “Up to Date”, while the Remote Device (i.e. PC ‘A’ where the folder is set to “Send Only”) is reported with hundreds of “Out of Sync Items”?

How can a “Send Only” folder have Out of Sync items at all?

What’s more, all of these Out of Sync Items are reported as “Modified by B” – whereas on “B” they definitely have not been touched, ever?

Send only folder having out of sync files means it has modified the files locally.

It says that latest version in the cluster are files provided by B but local changes were made on A. Changes on A are not sent back, hence why all changes that were sent to the cluster are made by B, which happen to conflict with changes by A, but those are never sent.

Audrius, I think you mixed up send-only and receiv-only there.

It’s the other way around for send-only A: B made changes and A refuses to sync those, so is out-of-sync. If you want to undo the changes on B, you need to press the override button on A.

Yeah, but B didn’t make those hundreds of changes – only 15. Many of the alleged changes on B are reported as being made in like 2003-2008, which is a decade before B even existed!

How is that possible?

And how come that there is no “Revert Local Changes” button on B?

OK I guess this is due to B not being set up as “Receive Only”. Only then, a “Revert Local Changes” button would be present, correct?

For the rest, I shall provide screenshots asap because I think it is very strange.