Also randomly doing -reset-database is likely to lead to conflicts as well.
1 Like
Sounds reasonable, yet if *.tmp is added at a later point to .stignore on both A and B, and all .tmp files have been deleted from both sides, then such files should be removed from the database and the devices should show each other as Up to Date. Instead one of them shows the other as syncing. Is this a logical error? How do I correct it without resetting the database?
Is it possible to sync .stignore between A and B and how?
.stignore has #include directive which can include a normal synced file. Itâd all in the docs.
Syncthing usually does not delete anything from itâs database, even if the file is deleted, because itâs usually not sure that every device has observed the deletion. I think there was some work to improve that but I am not sure if it landed.
As for your example, please write it up as a reproducible step by step guide, that youâve tested yourself in isolation and verified it works, and weâll have a look. From what you described, it should not behave that way, but again, you havenât provided steps to observe this ourselves.
Thank you Audrius! 
I assume #include path/to/.gitignore should do the trick. Do I need to restart Sincthing to detect the changes? I will try to make a step by step when I find some time and write an update.
You mentioned many times that Syncthing is designed to be used in a very specific way so I would like to share a short story from when I started programming in school. I was highly motivated and created a project hoping to impress my good teacher. He crashed it instantly and told me not to come back until I make sure it cannot be used incorrectly. And so I did. Lesson learned: when we create a program we expect it to be used in a certain way. In reality users will use it however seems logical to them and we have to consider that wonât be harmful.
Someone is already in the process of doing that: Add steps for using globally ignored patterns by KeyWeeUsr ¡ Pull Request #471 ¡ syncthing/docs ¡ GitHub
Nobody is saying thereâs nothing to improve (I mean, otherwise what would be the point for me to work on Syncthing). The point is we need to know what exactly is going wrong. Until now you only write up huge production scenarios where something didnât happen the way youâd want it to. Detailed information has been lost (-reset-db) and you havenât come up with steps to reproduce the behaviour. So we are not saying you are wrong and Syncthing is perfect, we are saying we need a way to understand what goes on. Only then can we think about potential bugs or improvements.
1 Like
Here are a few steps to reproduce some of my issues:
Last couple of days I decided to follow authorâs advice and #include path/.gitignore from .stignore, in order to sync the ignore list among devices. Then I moved some projects to different locations. A and B were in sync all the time, and everything was fine, but later I noticed that .gitignore ignores itself so I had to remove that. At that point A and B were in sync. C was behind, because B and C are the same computer. A, B, and C have an independent copies of my documents.
- A is Windows 10 on desktop PC
- B is macOS on MacBook Pro 2018
- C is Windows 10 on MacBook Pro 2018.
Then A suddenly started recreating empty folders which used to include .gitignore. These folders were not present on B. No matter how many times I deleted them, they were instantly recreated. And it canât copy them from C, because like I said B and C are the same device and B is online, so C is offline. Please correct this bug! Despite all warnings the only workaround is running -reset-database and -reset-deltas on all devices. After the reset, A and B eventually got in sync. Then I set A as Send only, shutdown B to start C, reset the database and set it Receive only to force it to catch-up. Things got quite messed up. No matter how many times I try telling C to revert all changes and accept what A is offering, it just did not listen to me. I had to resolve many conflicts manually, and restart A and C many times. Eventually I also had to -reset-database a few more times on both, until they got in sync. I also encountered errors where Syncthing said it had issues syncing a folder named §ŃМди where the actual folder name is ŃŃМди.
Two days later I noticed that some of my folders were renamed to random characters.
- Original folder: Visual Studio 2019\Settings
- Renamed to: Visual Studio 2019\321§
At this point, considering the many issues I have described, and especially related to changes in .stignore, Iâd like to inform the Authors that Syncthing requires urgent attention to correct the many bugs and prevent data loss. I no longer consider using Syncthing safe.
Note to the authors: I know youâre stubborn and hate me for being so honestly negative about your software. But please try to swallow your pride and understand that Iâve spent all my energy on this forum in hope to help you improve Syncthing. Because I see it has a great potential, and I personally regret to see that the actual implementation is so unreliable and easy to get into a state where hosts canât sync or old files are kept, while the new removed. You want me to reproduce the issues I encounter in a simple way. The thing is after I finish fighting all the issues, and get my computers in sync (which takes me days for what should take a couple of minutes), I have no energy or time to do anything. And my entire schedule is delayed by days which I need to catch up. Next time I should just screen capture the entire painful process and upload everything to YouTube for the world to see.
Sorry, but if we have no way of experiencing what you are experiencing, we have no way of observing the issue and finding the bug to fix it.
Describing seemingly random things you did and things youâve observed does not make it into an empirical step by step scenario of how we could use to observe this and fix this.
This has nothing todo with pride, but with lack of sensible information which we could follow to fix this.
If you are out of energy trying yo reproduce it, then donât reproduce it, but there is no point coming around complaining yet not providing the single thing that we need to fix this.
This adds no value and does not help actually solve the problem.
Also, you seem to be doing seemingly random things, .gitignore and .stignore are incompatible syntaxes, so I am not even sure what the result of that would be.
You are free not to use syncthing if you think itâs unsafe.
3 Likes
Thank you Audrius!
Regarding .gitignore and .stignore, looking into Syncthingâs documentation I see that the small set of features I use in .gitignore are exactly the same for .stignore. This is very convenient, because the ignore list is long and having to maintain a single copy simplifies things a lot. .stignore also allows to force sync a !file before including .gitignore, so I can exclude it from git, but sync it across devices. Iâm not an expert, and there might be differences, but as long as I keep the filters simple, it will be fine.
I agree that the best way of solving a problem is by having a simple step-by-step list of actions to reproduce it. I was also hoping that someone experienced enough in the program design would be able to follow my description and come with a possible reason.
Sorry, but I donât think we have anyone experienced enough in using a crytal ball.
What should I do if all folders show as Up to Date, but the devices show each other as Syncing 95% and this never completes?
Do you have a screenshot from the other side?
Itâs also possible this is due to https://github.com/syncthing/syncthing/issues/6335, which is currently being fixed.
Also possible due to ignoreDeletes?
Is that a good strategy, to decide on order of observation? That strikes me as strange. What is the reason for this?
Now we need to make sure we are talking about the same thing here: Syncthingâs primary âversion systemâ does not depend on system clocks. Reason is already given by Audrius:
More generally: Whatever one device uses as its time does not necessarily match anothers. Plus it wouldnât matter anyway, if two devices edit after each other in time but both based on the same old version, itâs still a conflict.
However when a conflict is detected within Syncthing, then modification times come into play when determining which to rename to the conflict file and which to leave as is. Here the file with the earlier mod time is chosen. Again due to clock inaccuracies this might be wrong, but itâs still better than flipping a coin to choose a file.
1 Like
Hi Audrius, I did not upload a screenshot from the other host, because it looked exactly the same. Ignore Delete is unchecked on all devices and I have never used this option.
Perhaps itâs the bug in quoted above then.
Suggest you try the new release candidate and potentially run the checking utility to see for database consistency.
@imsodin I did had a crash two days ago, when one of the computers A got a blue-screen while resuming from hibernation. Syncthing was running. I ran chkdsk /x on all disks. The bug you pointed to might be related to what happened next or due to a bad initial sync from the previous day: The next time I started Syncthing, it renamed Visual Studio 2019\Settings to Visual Studio 2019\321§, and propagated this to B. But the day before that I had a similar problem where another deviceâs database C had to be reset and then it complained about a folder showing its name incorrectly as §ŃМди, instead of ŃŃМди.
@AudriusButkevicius To make sure everything is all clean and consistent, last night I decided to -reset-database and then -reset-deltas on all devices. Remember B and C canât run at the same time. So I started with A and B, made sure they are in sync, then switched from B to C, reset the database and then it couldnât get in sync with A. Similar to the last screenshot. I have everything on video. So I was forced to reset the database again on both A and C and eventually they got in sync. These initial syncs after reset seems to be hard to achieve. Later I found that I need to change some files. I made sure A and C are in sync. Then restarted from C to B, but forgot to set A as Send Only and all changed files got sync-conflicts with B. I found that the best way to keep three devices in sync when only two can be active at the same time is to restore the same files and ignore list on all devices, then reset all databases, then sync A and B, then A with C and then A and B again, without changing any files. What I learned in this process is that since B and C cannot communicate directly, they communicate over A. All devices are set as introducers to each other. I also learned that making changes to the ignore list needs to be reviewed, because it is the source of many problems.
Audrius, I recorded almost 2 hours of screen time on A and C simultaneously. Would you like me to share them and should I edit them or leave the raw material? For me the easiest thing to do is to upload them to my server. VLC can open the AVI files created by Camtasia Recorder. I can also encode them to .mp4 or upload to YouTube, but that would take many hours of my time, especially if I have to edit or cut boring scenes. I should at least cut a few parts where the API key and a few passwords were revealed by accident. The videos show more details to what I have described here, but include a long and boring rescans after a few database resets until A and C finally get in sync.
If you had any crashes, itâs very likely you were affected by a bug fixed in 1.4.0. So any out-of-sync issues in that context donât need to be investigated until you get them again on 1.4.0 (also out of that context I would just update to 1.4.0 to rule out any issue related to that fixed bug).
As to your 2h screen record:
I suspect thereâs still a misconception on your side: I (and I am quite sure also Audrius/others) do not doubt that there are problems with Syncthing in your setup. Let me repeat that: I do believe you, that you get unexpected behaviour by Syncthing. And unexpected behaviour is always bad and there are likely things to be improved in the code, UI and docs related to that behaviour. No need to try to hammer that point home any further.
Separately nobody has the time to watch a 2h screencast. That statement is blunt, but I hope understandable.
What we want/need, is either a clear reproducer, which requires a setup we can reproduce. Your entire production system is not reproducible for us. The other option is you debugging the entire thing yourself with guidance from us. That also needs reduction of the problem (which Iâll try at the end).
Then back to what you did, the problem is here:
The problem is the db reset on A and C but not B. Lets go through the process with an imaginary file âfooâ:
- foo in sync on A, B and C with version
{B:2, A:4}(whatever). - Reset db on A and C: foo has now version
{A:1, C:1}on A and C and the version above on B (not connected). - Change from C to B: A and B compare foo and see the version conflict.
So now as to what might be able to be diagnosed:
That sounds like a problem already. At this point, stop⌠Really just that simple. Donât add new problems, it will just make it harder to find out what went wrong here and anything following might just be a consequence of what is happening here. Let me write down the steps in my words the way I understood them:
- Reset db on A and B.
- Connect A and B, let them get in sync.
- Shutdown B, start computer C (but not Syncthing C).
- Reset db on C, then start Syncthing on C and let it sync with A.
Result: C does not get in sync with A.
Expected: C gets in sync with A.
Is this correct?
If yes, start by querying GET /rest/db/file â Syncthing documentation for one of the out-of-sync files on C and A and posting here.
And one more thing: If B and C can never be online at the same time, donât directly connect them. Thereâs no point, they will never exchange information (because how should they) and thus look out-of-sync all the time to each other. Just both connect them to A and they will sync data with each other over A as they should.
2 Likes
Thank you, @imsodin! Your description is very systematic and easy to follow 
Now I understand more about the versions and how they are affected by a reset; what to avoid and what steps to follow for better reliability. If A and B are introducers to each other, and A and C are also introducers, then B and C know about each other even if they can never meet. I thought it would be convenient because if I share a folder on one device, the others will offer me to accept it. But youâre right, thereâs also a downside complicating the sync process. Querying the database will be very helpful to understand the problem. Iâll let you know as I have an update!