So, today I made a backup of an SD card with dd (the Unix utility). This was on my laptop, whilst my desktop was powered with Syncthing running. I did not touch the backup file on my desktop as it was being synced, however Syncthing managed to create 6 sync-conflict files. 6! Whilst my desktop didn’t make any modifications to the file! It even made a sync-conflict for another sync-conflict.
(File at the top is the original file)
This is not the first time I’ve seen this. Syncthing litters all my shared directories with “sync-conflict” files. I share some git projects between my devices with Syncthing and I have seen it create entire new branches with “sync-conflict” in the name, but this is by far the worst I have seen. I came from Btsync and it didn’t have these issues (it had other issues, however). So, basically I have two questions:
How do I stop Syncthing from making sync-conflict files when there’s obviously no conflict?
How do I get Syncthing to put its sync-conflict files in some other directory (like Btsync did/does), so that they do not interfere with special programs reading the files
I still want sync-conflict files when an actual concurrent modification occurred. I don’t wanna lose work.
Both my systems run Ubuntu. My laptop runs 14.04 LTS and my desktop 15.04, both x64. My file systems are ext4 everywhere and I haven’t done any special stuff like running a custom kernel.
Syncthing is awesome, and I would love it if this could be fixed.
Thank you for your time.
I think you’ll actually have to show that there’s no conflict here - i.e. that the “Foo.sync-conflict.xxx” has exactly the same content as the corresponding “Foo” file.
The contents of the various sync-conflict files are obviously not the same as the file sizes differ (by quite a bit). I think it made the files whilst the original file backup was growing to the size it is now. I think it went a bit like this:
Sync the file with my desktop
Notice the file on my desktop is no longer the same as the one on my laptop
Create a sync-conflict copy on my laptop
However, it shouldn’t do that if the file on my desktop was never modified.
If it did do this, that would be a fairly large bug in the way that Syncthing’s versioning system works. You’ll have to provide some evidence / a reproducible case which shows that this is actually happening.
Until that point, it’s most likely that the file on your desktop was changed. Might git have done this? Were you using the git repo on your desktop?
No, this was not inside a git repository (sorry for the confusion there). The only thing that I can think of that might have touched the file is Gnomes search indexing system, but it would never write to it. It could however read from it and with that change some timestamps?
Do you know what triggers a resync in Syncthing? Does it actually check the contents of the file (by MD5sum or something like that) or does it work based on timestamps?
I think it’s timestamp, backed up by a sha256 hash. Certainly once we get as far as the protocol everything’s done based on the sha256 hash of a 128 KiB block. Versioning is handled by vector clocks, which correctly handles multiple changes by multiple devices, even when they are not directly connected.
It may be that an mtime update triggers a version bump, since the mtime is considered part of the metadata which is synced (I think?). @calmh?
So basically, what you are saying is that there’s no way that Syncthing syncs a file without a program actually modifying it. In other words, I need to go find whatever program felt like it had to write to the file? Is there any easy way to do that?
You can run with STTRACE=scanner env var set on the device which is supposedly not touching the file, to see it pick up the changes to prove the point that it is being modified by something.
Also, if you are syncthing git repos, you are begging for trouble. git is not a single file, it’s a collection of files, and suddenly syncing some files from two different locations of the same state will probably make you loose that repo in both locations, as you will get it corrupt.
I had a similar problem and wrote a little script to get rid of all the identical “conflict” files.clean up syncting mess v2.ps1 (2.8 KB)
It is a windows powershell script. It compares the hashes of all files in a folder and leaves only one. Then it renames the latest file to the original name. You can try it if you know what you do. It comes with no warranty whatsoever. You should know what you do. It delets files!
