Hello,
I’am getting a lot of conflicting files with 0.14.48. When I save a file in blender, its sibling with .sync-conflict-… apperars in several moments. For each save one new conflict file.
It seems like a bug?
Look at the change log to understand where the changes are coming from. Also, diff the files, I suspect you’ll find that they are actually different.
They shouldn’t. I have four computers synchronized and I’am saving blender files only on one of them.
Where can I find the changelog, please?
It’s the Recent changes button in the web ui. The fact that you saving the files in one place doesn’t necessarily mean that other computers are not opening those files as they get downloaded and for example generating thumbnails, or adding some metadata to the files. If all other 3 are doing that, it explains the conflicts.
You can diff the files to see what has actually changed, which perhaps can help you make some conclusions.
It seems, that the problem emerges when I save the file again before last version is uploaded to network. Here is relevant part of log
infiwo added file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.sync-conflict-20180627-212044-SNEDSDQ.blend 2018-06-27 21:20:55
infiwo added file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.sync-conflict-20180627-212042-SNEDSDQ.blend1 2018-06-27 21:20:53
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend 2018-06-27 21:20:45
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend1 2018-06-27 21:20:43
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend1 2018-06-27 21:20:37
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend 2018-06-27 21:20:37
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend1 2018-06-27 21:20:35
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend 2018-06-27 21:20:35
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend 2018-06-27 21:20:32
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend1 2018-06-27 21:20:31
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend1 2018-06-27 21:20:30
infisky modified file 0Work Cons-Dablice-Kvetnova/50-Model/link-domy-180622.blend
I’am pretty sure, that other computers doesn’t change the file. And I had no such problem with 0.14.47 version.
If useLargeBlocks is enabled on only one side and there is some sort of metadata/timestamp funkyness on the other side, this could be the effect…
Sorry for interruping, but if “useLargeBlocks” can cause this bad effect, can you add a reminder in Syncthing, like “Other side using useLargeBlocks, Press yes to enable it on your side”?
The setting is not generally visible, and we assume people will go enabling it after reading the docs, where it explains the pitfalls.
Yes, but if nodes are not too close - people can forget to enable this feature.
On infiwo I don’t have this setting enabled. On infisky probably neither, I will check it later. It is a home computer.
I also saw some conflicts for files that were only changed on one side and synced to some other devices (not sure when it started, could be 0.14.48), no large blocks enabled here. Did not have time to investigate what the contents are (deleted conflicts and pressed save again because I had the file open).
In my case, all of them have Linux, three times Ubuntu 18.04 and very old Debian 7.11 on the fourth.
All that share the folder are Linux with ext4 (Ubuntu 18.04, Ubuntu 16.04 and Raspbian stretch) - there are other windows devices that I use, but none has this folder. One thing that is probably worth mentioning is that the files where this happened were modified often and quickly with filesystem watcher enabled (multiple modifications before the slow raspberry pi finished syncing).
And infisky has useLargeBlocks disabled as well.
I just reproduced “this” and it is already fixed in master (i.e. will be fixed in 0.14.50). In quotation marks because obviously I can’t be sure it is the same issue, but I found “a” issue that only exists since 0.14.48 and can lead to erroneous conflict copies:
-
Initial state: Two devices A and B with a file F that was previously modified on both devices, i.e. the version vector must include both IDs. For easy reproduction, disable watch for changes and use a high scan interval on A (you don’t need to interact with B).
-
In A’s UI, pause device B.
-
Add random data to F and scan it.
-
Again add random data to F, but do not scan it.
-
Unpause device B.
Actual: Conflict copy is created.
Expected: Just update the file, it was only changed on A.
This fits with the descriptions that this happens with files that are often changed. The problem was introduced in https://github.com/syncthing/syncthing/pull/4767 due to changed but valid files being marked as invalid on request -> conflict. https://github.com/syncthing/syncthing/pull/4952 already fixes this issue by discerning between different types of invalid files and not conflicting files, that were marked to be rescanned.
@VaclavC, @Alex Please report back if this issue still persists in v0.14.50.
1 Like
Just to add my few cents: I’m also facing this issue quite a lot recently (probably since v0.14.48)
no paused devices or folders, useLargeBlocks is off, file watcher is enabled
While saving a file frequently on device A (i.e writing a document/text file), conflicts get created locally a lot, with the self-ID (A’s ID) appended.
On other devices the file in question was never modified, in a sense that - it’s A that created a “conflict with itself”, and no “real conflict” occurred.
Came to report the same thing - lot’s of conflicts caused by one-sided modification, especially during git checkout (ie. a quick change scenario). I’m glad to find this thread and will be waiting for the 14.50 now. Are there any tips how to avoid this effect for now?
No real patent solution I think. If it is an option for you, you could disable watch for changes and put the rescan interval to something longer than the interval you are continuously changing a file (e.g. longer than what you need to edit a photo). Thus you increase the chance that the change info will only be sent to the remote after the file is in its final state -> no conflict.