Syncthing recreates deleted files / creates conflicts

Support
1

Hey, Syncthing gurus,

I have two Linux (ext4) nodes running v0.14.50. If I create a file on node A, it syncs to node B. If I delete it on node A, node B recreates it on node A. If I modify the file on node A, node B creates a conflict on its node and then syncs the conflict back to A. This is what the log says on device B:

2018-11-14 21:50:13 Puller (folder “documents” (documents), file “path/to/file”): delete file: file modified but not rescanned; will try again later

In reverse, if I create a file on node B, everything works fine - files are deleted and there are no conflicts.

Any ideas?

2

Do you have ignore permissions enabled on either side, or did you do case only renames?

3

I have exactly the same problem. But within Windows+WinServer. No fancy stuff enabled, only uselargeblocks. " If I create a file on node A, it syncs to node B. If I delete it on node A, node B recreates it on node A. " I had this with 1000 files. Syncthing created 1000 syncthing~ files^^. I had to remove the directory from the sync directory, wait wait wait and move it back for it to sync propably.

4

This does not necessarily answer my question, as some things are enabled by default on some OSes.

5

Since i only use Windows (Android with other folders) i have never enabled or used ignore perms or ignore deletes ever.

6

Hello @AudriusButkevicius, and thank you for replying!

Both sides have ignore permissions disabled, and if by “case renames” you mean changing the name of the file to upper or lowercase, I’ve not tested that. The problem occurs when deleting the file or modifying its contents (i.e. changing file size).

However, I was wrong in my original post, for which I apologize - while both machines run Ubuntu, node A is in fact ext4, while node B is a mounted NTFS drive (using “ntfs defaults 0 0” in fstab, which results in Ubuntu mounting it in a folder, in which all folders and files are owned by root.root and with permissions 777).

7

I think ntfs does not aupport unix permissions, so you save a file and it straight away starts having different permissions, and the permission change looks like a conflict. Ideally you would enable ignore permissions, but there is a bug in conflict checking that ignores that flag, so it still ends up with a conflict.

I suggest you upgrade to latest release candidate that has this fixed.

1 Like
9

I understand, thank you for your help. Any idea when this bug fix will be released in a stable version, so I don’t unintentionally mess up my current set up?

10

Fiest few weeks of december

1 Like
11

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