Hey all, I am new here but have been a long time user of Syncthing across a multitude of devices and recently I have noticed something very interesting that I am sure has been addressed somewhere, but I couldn’t find a post with specifically this issue.
Essentially as the topic title describes I am not creating a ton of Syncthing conflicts using the Synctrazor for Windows on my Windows 11 desktop. If I create a new text file, ODT document, or any other file that I then begin to edit in real-time, after a second or two I get a Syncthing sync conflict. The odd thing is the conflict is created by my desktop itself. So whenever I save 3 times in quick succession after minor changes, I have 3 conflicts all created by the desktop that I am actively editing on.
The device I am syncing too right now is simply a Lubuntu server I have and all these shares that I sync against are on a DAS that is attached to it.
Until recently I noticed I had a version mismatch between the Unix server and my desktop, but I got the apt repository for Syncthing properly hooked up to my apt lists and it is up to the same version as the Windows 11 desktop.
I am not sure yet what information could help in this case, but please let me know what all you would need me to share to help in figuring out if this is as a I fear and simply a network speed issue or if there is something else at play here.
So I just checked, Synctrayzor on the Windows 11 PC is using version 1.23.1 of Syncthing (and Synctrayzor itself is version 1.1.29) and I just noticed that Syncthing on the Linux server was running 1.23.0. After running updates I see it is now on the same version 1.23.1. I am going to re-create the issue with the matching versions now and see if it is still happening since it definitely wasn’t available from the syncthing repo I was getting updates from before just a few days ago.
So sure enough it is still doing the same as it was before.
For context the desktop under modified by is the hostname of the desktop I made the file on. It seems that for some reason with these newer versions of Syncthing, there is some kind of delay in the creation of the file on my linux server if I am actively editing and every time I save it thinks that my desktop is conflicting with files that are on the linux server, but it is just based on some kind of delay for some reason.
So this actually made me hope it could be something this simple, but if .0002 seconds difference is enough to cause this issue then I am afraid this is not it either. My desktop (the Windows 11 PC) is the one that is .0002 seconds fast apparently and the Linux server is exactly on time compared to that site. So if that makes a difference maybe, but I assume it does not.
I should add I never noticed this when I was on Windows 10 prior and it only really just started. I thought it could be the new router I got but I am not sure.
Syncthing has a default 10-second time delay when it’s notified by the host OS about filesystem events, i.e., create/save a file and there’s a 10-second delay before Syncthing initiates a folder scan (delete events are a 6x multiple = 60 seconds).
Generally speaking text and word processing programs don’t save changes in real-time, so while editing Test.txt, changes are buffered in memory until the [Save] or equivalent keyboard shortcut is pressed.
Then due to disk caching in most OSes, a file save almost never results in an immediate buffer flush to disk (RAID controllers and controllers in SSDs add yet another intermediary).
Check out Syncthing’s debugging facilities (Actions → Logs) for info about what’s happening behind the scenes.
(In your screenshot, have you determined why the conflicting file size with the newer timestamp is zero?)
So for added context, it is not always zero. Rather it is whatever the file size of the file was when I started. So if I create Text.txt and it is an empty 0 kb file the edit will have added say 1 kb to it in this case. So if I came back later to the save 1 kb file and added 2 kbs of data to make it 3 kbs, the conflicting file would be the original 1 kb and the one it conflicts with is the current saved 3 kbs file. That is just how I have observed it so far.
Also just to add in an edit, I will check the logs and see what is happening in these cases cause as I said, its a relatively new thing that I have noticed.