I have a rather large folder, both in size and in number of files (231000 files, 11160 folders, 333 GiB), that I sync between a Windows 10 machine (A) and a Debian machine (B). This has been working nicely for many years, but after upgrading to ST 2, I have started having problems. They have mostly been benign but the latest issue is so bad I need your help.
I moved a folder on B from outside the synced folder to inside it. Then I did other stuff while waiting for the folder to be completely synced to A.
When I opened the folder, all the files were renamed “*.sync-conflict-(Id of machine A)”.
On machine B, the same had happened (also with the Id of machine A).
Visually comparing the files, I can’t see any differences.
Can you please help me with two things:
What can I do to restore the folder? There are thousands of files that are currently unusable.
What can I do to investigate the issue, to see if the problem is me, my configuration or Syncthing. And if the latter, how to gather information that can benefit you.
Machine A: Windows 10 with extended updates. Syncthing 2.1.3 Build 2026-08-03 installed as a service. The folder has no versioning and Block indexing and Ignore permissions set.
Machine B: Debian Trixie. ZFS filesystem. Syncthing 2.1.3 Build 2026-08-03 installed from apt.syncthing.net. Installed as a systemd service. The folder has no versioning and Block indexing and Ignore permissions set.
I can’t fully visualise the problem. You say the files were renamed to sync conflict files, which should never happen afaik. You also say you compare files visually, not sure what you’re comparing to what. (Are these photos? The typical source then for sync conflicts is some other program immediately and automatically writing to the file to update some metadata in it.)
You’re asking what to do to restore the folder; if the sync conflicts are spurious, and they were copies as they should be and not renames, you can remove them.
As for investigation, I’d first consider if there’s some other program, either syncing or otherwise updating the files (metadata indexing with write-back to in-photo XMP data or something like that).
They are not renamed? Then I have misunderstood something!
So, before syncing, the folder contained a file called “audio_credits.txt”.
After sync there was only a file called “audio_credits.sync-conflict-20260829-161614-TEQOE4Z.txt”, but it still contained the same text.
So I interpreted it that syncthing had detected a change somehow (in metadata, I assumed), while also believing that the other device had a change. And that it renamed the file as a result.
Although, I would have expected the other device to do a similar rename, but with its own device Id in the name. But on both sides, I find the exact same file, with the device Id of device A.
But if I understand you correctly, I should have had two files on each side?
One with the original name, and one with “*.sync-conflict”?
Yes. When Syncthing syncs a change from another device, and discovers that the local file has also changed (content wise) in the meantime, this is a conflict. One version becomes the winner and the other the loser - the winner stays as the regular file name and the loser becomes the sync-conflict copy.
If you have no original, I don’t know what’s going on.
If the conflict is that one side thinks the files have been deleted and the other side don’t, would the result be what I see, i.e. only the “sync-conflict” file?
There can be a conflict if one side changes the file (or metadata) and the other side deletes it, while neither has heard of the other one’s change. In that case, I’m not sure if the deletion can win and thus the original vanishes while the modified version ends up with the conflict name. There was a change in that regard in recent versions, where a deletion can win a conflict situation in principle, which used to be impossible.
In any case, if one device creates a conflict file, it’s synced to all others just like any other file. Nothing special about the name here. You could add an ignore pattern if you want to keep conflict files local.
Ignoring the conflict file would just mean that I have no file on one side, once the delete wins. And it would also mean more moving parts when I try to find the cause.
So, back to the core issue, I see no logging facility that seems to be focused on conflicts. Do you have any suggestions for where I could start?
Or perhaps I should stop thinking about the conflict and instead figure out why the files are considered deleted by one side. Maybe it’s some kind of race condition. It happens when I drag a large directory tree into the folder. Maybe the target creates the directory tree first, without files, and then gets confused wether the files has been created or not.
The linux machine is a Raspberry Pi 5, with a good amount of RAM and an SSD-cached hard drive. I find it extremely snappy for all use cases, but perhaps it is too slow, thus creating confusion when a large amount of changes come at the same time.
Remote: Syncthing 2.1.3 Linux (64-bit Intel/AMD); Filesystem: Ext4
No original retained on either side.
The File sizes differ between local and remote, which is probably caused by how btrfs and ext4 store the files, but of course a modification cannot be ruled out and without the backups it’s hard to find out which one is the original or which one is closer to the original.
I do have backups, but I might have to redo some of the work I did in the last two days.
My hypotheses why this happened:
Maybe I moved a bunch of files while syncthing was on, too often, too fast between folders and the interaction between btrfs/ext4/syncthing/local network traffic (70Mbit/s) couldn’t keep up speed-wise.
Maybe multiple apps tried to access the files at the same time:
the literature management software “JabRef” to index the files for an app internal search engine.
baloo (KDE’s Desktop search engine) indexed them too
And just to double-check; your files could have been accessed by other processes while syncthing was working, but none of them should have deleted files, probably only read them?
On that day I manually moved a lot of files around, because I tried to identify broken PDFs (not Syncthing’s fault). JabRef and baloo should do read-only I think (I manually triggered JAbRef’s indexing a lot, because I was debugging something. Indexing is required if I want to utilize JabRef to search within the PDFs), but I cannot rule out they modified something in the file. For that one would need to look at the code.
