Syncthing v1.6.0 / v1.6.1


This release performs a database schema migration, and adds the BlockPullOrder, DisableFsync and MaxConcurrentWrites folder options to the configuration schema.

The LocalChangeDetected event no longer has the action set to added for new files, instead showing modified for all local file changes.


  • #3876: Removing and re-adding a folder may cause data loss
  • #5731: 100% CPU every minute on watch setup retry
  • #6268: Out of sync panel layout overflows
  • #6557: Folder error repeatedly set and unset
  • #6559: Deadlock on folder unsubscribe
  • #6576: Versioning params in config flip flop in order
  • #6578: Allow rescan at folder state “Local Additions”
  • #6583: Distributed deadlock on request
  • #6604: Docker healthcheck fails when run in host network


  • #5224: Accept new connections in place of old ones when appropriate
  • #6530: Add “Pause All”/“Resume All” button for devices
  • #6541: Limit number of concurrent writes while syncing

Other issues

  • #6575: Incomprehensible error message: ‘directory is not empty; files within are probably ignored on connected devices only’
  • #6584: A field in a structure is sometimes protected by Mutex, but sometimes unprotected.


This is a fixup release on 1.6.0 in order to restore the auto upgrade critera broken in 1.5.0.


  • #6701: Syncthing 1.5.0+ auto upgrades even with auto upgrades disabled in config
1 Like

Hello - hope you are all safe and well.

Just wanted to impart a bit of positivity into the world: I’ve been fighting (again…) with a NAS with limited RAM and many files that had got itself way out of sync with a peer (I suspect someone had moved a big bunch o’ files on one machine); running v1.5.0, Syncthing would get killed after about 12 hours, whilst it was Preparing to Sync a large folder.

I applied all the tweaks I could find to reduce the memory, and was in the middle of investigating further, but saw v1.6.0 was on the horizon, and might help my situation.

Having let the system upgrade to v1.6.0 then v1.6.1, I’m pleased to report that 19 hours later, Syncthing is still running very happily thankyouverymuch. It appears to have got through whatever was causing the high RAM footprint, and has now got itself into an ‘Up to Date’ state. :slight_smile:

I was going to post that there were still some files missing from one side - but I see that there’s a whole load of index exchanges going on - so I guess it’s still getting its house in order (indeed, the Global State does not match between devices too). But this is much further than it got under v1.5.0 - so thankyou thankyou thankyou yet again!

Obviously I don’t know the innards and how easy this is to reliably detect, but: given there’s a whole load of index exchanges happening, surely the ‘Up to Date’ status is misleading? Is there an argument for setting the status to ‘Receiving Index Updates’ on the receipt of an index update, until either a ‘Preparing to Sync’ or ‘Up to Date’, etc status is triggered?


This topic was automatically closed after 30 days. New replies are no longer allowed.