Syncthing generates cnflicts when file only changed on one device

Support
1

Similar to previous topic (conflicts when file only changed on one device), but I don’t use nfs.

I’m using syncthing to sync code betweeen Windows 10 (local), and two Linux machines (remote). I’m editing code on local machine, run compiler and get a lot of sync conflicts. Strangely, syncthing thinks all conflicted files are originated on local machine, which is strange. Any way I can debug / fix it?

I’m using v1.18.4

2

My guess would be you have an IDE open on some of the other machines, which auto builds/formats/resaves/whatever causing conflicts. I’d debug by shutting down stuff on the other machines.

3

Nope, there are no IDEs open on remote machines. These machines are for passive storage only. Moreover, conflicts are created when I put remote machines on pause in remote devices. All conflicting files created by SyncThing have suffixes corresponding to the local machine id, and sometimes several such files are created (all corresponding to local machine). I assume that sync conflict means that file was edited on remote machine and local machine simultaneously, and suffix (the XXXX in filename-.sync-conflict-DATE-TIME-XXXX.ext) corresponds to the machine on which the particular version was created.

4

Indeed. I have no idea how that can happen if there’s no modifications from the other side.

5

You can run syncthing cli debug file <folder-id> <file-path> on either/both the original and conflict file, and the version vector will show which remote device was involved.

1 Like
6

Results are same for original and modified files:

{
  "availability": null,
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "1969-12-31T16:00:00-08:00",
    "modifiedBy": "",
    "mustRescan": false,
    "name": "",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0",
    "sequence": 0,
    "size": 0,
    "type": "FILE_INFO_TYPE_FILE",
    "version": []
  },
  "globalVersions": "{}",
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "1969-12-31T16:00:00-08:00",
    "modifiedBy": "",
    "mustRescan": false,
    "name": "",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0",
    "sequence": 0,
    "size": 0,
    "type": "FILE_INFO_TYPE_FILE",
    "version": []
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}
7

That’s equivalent to “not found” (all default values). Please double check you are using the path relative to the folder root, e.g. “foo/bar” when the abs path is “/folder/root/foo/bar”.

8

I digged into the json generated by syncthing. It turned out that conflicting version was generated on a Linux machine (Raspberry Pi), where synchronized directory was shared by SMB. Can that be a source of a problem?

9

Yes, smb/fat potentially loses permissions/timestamps as we try to set them ending up generating conflicts.

1 Like
10

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