Hi Syncthing crew! I’m a super happy user of Syncthing to keep bidirectional sync between my Windows 10 laptop and my linux box for development activities. Everything goes usually very smooth (few seconds only until small files are all synced). However, as soon as the number of files is not trivial anymore (>500?), it seems that syncs are no longer made on the fly and I have to explicitely click the rescan button and wait for 10+ seconds… Currently with my 6000 files in 3000 directories (post stfilters), it never reacts to filesystem changes any more and I have to wait for a trigger rescands automatically 100% of times. At least in the Windows->Linux direction. Am I doing something wrong? This leads to tons of waster time, interruptions, and unwanted conflicts when touching files on both machines even dozens of minutes aside. Many thanks, Cyril
There are no known problems with watching for changes and lots of data/changes.
Changes are batched up some time. All changes are buffered for 10s, and repeat changes to the same file for up to 6 times as long (60s). All deletions are buffered for 6 times the base duration. This is the default value, you can set it through fsWatcherDelayS.
I think I’ve been seeing this same problem (Windows too) but I think only one one repo of 4600 files / 1300 folders, not my largest in item counts. I’ll spend some time looking into it in more detail.
Thank you so much for youer replies. Simon, thanks for clarifying the semantics of fsWatcherDelayS (especially the “fsWatcherDelayS x 6” rule which applies a lot when e.g. editing files in an IDE on windows and building on linux). Which leads me to some more questions if you will 
- can I influence this factor (e.g. reduce 6 down to 3)
- what is the implication of setting aggressive values? e.g. fsWatcherDelayS=1
- what is the best approach to watch/debug the whole chain from e.g. my windows box’s perspective? I’m thinking getting instant visual feedback when syncthing captures a local file change event from the OS → filtering against reduce patterns → aggregating more local changes → publish them for propagation to remote devices → acceptation by remote devices? Many thanks, Cyril
No. And thinking again it might even be factor 10, not sure anymore. And the longer duration is capped at 1min I think.
More internal churn, less chance to pick up files which are moved, … However I wouldn’t expect anything bad to happen.
Answer I’d like to give: Don’t do it. If you want to build code instantly, use something that’s meant for doing that (IDE hooks?).
If you really want to observe in real time you might get lucky and you see something in the web UI, but for small changes it might never show as scanning/syncing. You could enable lots of debug env vars and then pipe that through a filter to get relevant lines, but really, you don’t want to do that unless you are really digging deep into debugging an actual problem.
Thank you so much Simon for your answers. I’ll try to test with a few different values of this setting. I guess my question regarding visualizing the events in real-time is for me to understand whether there ise actually an issue with the detection at all or if it is just slow to pick up even the smallest, isolated change in e.g. a source file. Right now I have the feeling that I’m left pretty much blind when syncing is not happening. I’m gonna look into IDE hooks. Cheers, Cyril
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.