Syncthing

Recent Commits

• Jakob Borg(24 Aug 26)

  chore: set User-Agent on all outgoing HTTP requests (#10867) It's only polite, and it enables better troubleshooting in situations like weird-ass requests to the upgrades download service. --------- Signed-off-by: Jakob Borg <[email protected]>

• Syncthing Release Automation(24 Aug 26)

  chore(gui, man, authors): update docs, translations, and contributors

• Jakob Borg(20 Aug 26)

  build(deps): update dependencies (#10865) Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(19 Aug 26)

  build: use Go 1.27, minimum version is Go 1.26 (#10864) ### Purpose 🎉 Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(18 Aug 26)

  Merge branch 'infrastructure' * infrastructure: fix(stdiscosrv): slightly increase reannounce times and smoothing fix(stdiscosrv): 500 errors should be accompanied by log entry fix(ursrv): data problems are the clients fault build: sign docker images

• Jakob Borg(16 Aug 26)

  fix(stdiscosrv): slightly increase reannounce times and smoothing Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(15 Aug 26)

  fix(stdiscosrv): 500 errors should be accompanied by log entry Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(15 Aug 26)

  fix(ursrv): data problems are the clients fault Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(26 May 26)

  build: sign docker images Signed-off-by: Jakob Borg <[email protected]>

• Syncthing Release Automation(17 Aug 26)

  chore(gui, man, authors): update docs, translations, and contributors

• Jakob Borg(11 Aug 26)

  fix: open GUI when relaunched instead of printing error (fixes #10727) (#10852) This is primarily to improve the experience in environments that start Syncthing from a graphical environment, e.g., Windows. When already running, instead of printing an error we open the GUI. If the GUI is not available (but the lockfile indicates we are running), print an error and exit. If --no-browser is given or STNOBROWSER is set, act like before. Closes #10736. Marking as `fix` because this does not deserve to trigger a minor release on its own. --------- Signed-off-by: Jakob Borg <[email protected]>

• Syncthing Release Automation(10 Aug 26)

  chore(gui, man, authors): update docs, translations, and contributors

• Jakob Borg(05 Aug 26)

  fix(api): correctly return metrics, support bundle (fixes #10847) (#10849) Our faked request wasn't good enough; improve it, adding a test. Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(05 Aug 26)

  fix(model): correctly handle receive-only changed directories (fixes #8004) (#10843) When adding a folder in receive-only mode where the contents were already identical to a remote device, directories would remain as locally changed when everything else had consolidated. The reason this happened is that we only did the matching between locally changed files and their global equivalent for changed items, but directories are typically not "changed" much as we don't track their mtime, so they wouldn't pass through this stage when scanning. Now, instead, do the check when we're anyway walking all the files in phase two of scanning. This catches all cases of identical items, files or directories, regardless of how they came to be in the index. Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(05 Aug 26)

  chore: style fixes from `go fix` (#10846) Just `go fix ./...` Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(03 Aug 26)

  fix(db, model): better handle db connections, puller concurrency, avoid deadlock (fixes #10841) (#10842) There is a danger of deadlock wherever we have database operations inside a database iterator. The iterator itself pins a connection, so the nested operations need another connection; if we've reached maxOpenConns then it blocks until a connection is released. If all connections are consumed by such iterators then none can make progress. Luckily, we have limited concurrency for most such iterator loops. They are part of scanning, pulling, reverting, etc where there is only ever one such routine per folder. The exception is block reuse in the copier routine, which is limited by the `Copiers` setting per folder. This could in practice deadlock since you could set copiers to eight and end up with six `AllLocalBlocksWithHash` iterators when `maxDBConns=6`, all of which need to make additional database calls inside the loop. This PR fixes the problem twice; - The problematic loop does not need to be reentrant. The set of blocks that may be returned by the iterator is finite so we can easily just collect them to a slice before we start processing them. This avoids the problem entirely. - We do not need to limit database connections as strictly as we currently do. Increase the maximum allowed, while reducing the number of held-open idle connections slightly. This is not an exact science, but ideally we want "most" operations to be able to use the pinned connections to avoid cache churn. Most operations are short lived queries, or single-goroutine iterators with short lived queries inside, so four connections seems like it should usually be enough. 🤷 - Additionally, set a cap on Copiers. Currently you could set it to an arbitrarily large number, which is not advantageous. Limit it to 2*NumCPU which scales somewhat with system performance. Signed-off-by: Jakob Borg <[email protected]>

• Syncthing Release Automation(03 Aug 26)

  chore(gui, man, authors): update docs, translations, and contributors

• Jakob Borg(27 Jul 26)

  chore(syncthing): include local db entries in perfstats (#10839) As used by the latest few PRs with graphs in them Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(27 Jul 26)

  chore(model): optimise fsync calls (#10831) This improves performance when running with fsync enabled. The key observation is that the OS may coalesce multiple concurrent fsyncs, so we gain some performance by issuing them in parallell. Since they run from the finisher routine, a simple fix is to run multiple finisher routines. That's the `after` line in the graph below. The other step is to do the same for the directory fsyncs, issuing them concurrently with a limiter. In both cases I used the Copiers value as the concurrency factor. Additionally, add some buffering to the channels between routines to minimise stalls where a routine needs to wait for another. This is the `after2` line. All in all, this speeds up syncing 25k tiny files from 190s to 130s, a 30% improvement. <img width="821" height="540" alt="Screenshot 2026-07-25 at 22 58 34" src="https://github.com/user-attachments/assets/18272c89-a99e-4ee4-9b5e-b278967ea7c6" /> --------- Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(27 Jul 26)

  chore(fs): optimise casefs caching performance (#10830) This tweaks the casefs cache to do in-place updates for modifications we perform, instead of dropping the entire cache. That is, we add, remove and rename things in the cache after having done the corresponding operation. We still drop the cache entirely on larger operations like MkdirAll, and before Walk, and the 1s expiry is unchanged. The result is performance much closer to the original. I set up a device with 150 000 tiny files and measured the time it took for a blank device to come online and sync all the files, with default settings apart from `fsync` being disabled, as it otherwise dominated the benchmark... There are three runs, all are identical in the first 40 seconds which is the index transmission & reception, then we can see the `sensitive` run (casefs disabled) finishes at 137 seconds (137-40 = 97s spent syncing); the `before` run finishes at 238s (198s spent syncing); the `after` run finishes at 142 seconds (102s spent syncing). So, effectively the sync time is cut in half, and is now very close to having case sensitive enabled. <img width="812" height="476" alt="Screenshot 2026-07-25 at 23 22 22" src="https://github.com/user-attachments/assets/0aa39712-9fd7-46cf-969e-b6a20f150a3c" /> --------- Signed-off-by: Jakob Borg <[email protected]>

• Simon Frei(27 Jul 26)

  chore(model): don't check existing file twice in rename detection (#10833) This is related to and lessens issue: https://github.com/syncthing/syncthing/issues/10777 @SoongVilda found that a recent change to track already deleted or existing files only in the scope of a batch, also stopped tracking already existing files. Thus the osutil.IsDeleted check can be executed many times if lots of identical files get picked up in a scan: https://github.com/syncthing/syncthing/issues/10777#issuecomment-4991039201 The change in question: chore(model): more efficient tracking of renames during scan (#10653) 2721b7b5222ff414d02b35789a82028508918a8e --------- Signed-off-by: Simon Frei <[email protected]>

• Syncthing Release Automation(27 Jul 26)

  chore(gui, man, authors): update docs, translations, and contributors

• Jakob Borg(26 Jul 26)

  fix(api): handle empty path in static request (#10837) The panic would be recovered by the HTTP server, but this is cleaner. Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(26 Jul 26)

  fix(versioner): handle invalid empty command (#10836) Same same Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(26 Jul 26)

  fix(ignore): handle pattern resulting in empty string (#10835) Minor fix to avoid a panic in ignore matching. Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(26 Jul 26)

  fix(upnp): guard against out of index string access (#10834) Broken responses may have empty path component. Signed-off-by: Jakob Borg <[email protected]>

• Jakob Borg(25 Jul 26)

  chore: deflake TestRecvOnlyRevertNeeds (#10827) There was a rare, tricky race condition in the setup, where a pull could get started, find the blocks from the file we injected in updateLocalsFromScanning, copy them into a temp file, then fail the pull because the file was already in place. Then later, after the revert, another pull would start, find the temp file and reuse it, making it so needed=0 instead of the expected needed>0 the test checks for. This avoids all that by setting the local index data prior to getting it from the "remote" device, thus avoiding the initial pull and temp file creation etc. Signed-off-by: Jakob Borg <[email protected]>

• tbodt(25 Jul 26)

  chore(gui): better describe when a pending folder/device notification will reappear (#10808) The tooltip on the dismiss button for notifications confused me a bit (wdym mean "may" recur?) so here is an attempt at a clearer message. Signed-off-by: tbodt <[email protected]>

• Rohit Tanwar(25 Jul 26)

  fix(gui): add bottom margin to folder action buttons for wrapped spacing (#10728) adds a bottom margin to buttons inside panel footers, ensuring a comfortable gap between wrapped button rows. (Fixes #10689 ) Signed-off-by: rohitanwar <[email protected]>

• Jakob Borg(25 Jul 26)

  chore: slightly optimise rename detection (ref #10777) (#10819) Only run rename detection for new files. This skips an expensive check for all updates to existing files. The tradeoff is that we no longer immediately detect renames on top of another file as a rename -- this may instead become a copy+delete operation on the destination. --------- Signed-off-by: Jakob Borg <[email protected]>