Tags

v1.5.0

This release changes the default location for the index database under
some circumstances. Two new flags can also be used to affect the
location of the configuration (`-config`) and database (`-data`)
separately. The old `-home` flag is equivalent to setting both of these
to the same directory. When no flags are given the following logic is
used to determine the data location:

- If a database exists in the old default location, that location is
  still used. This means existing installations are not affected by this
  change.
- If `$XDG_DATA_HOME` is set, use `$XDG_DATA_HOME/syncthing`.
- If `~/.local/share/syncthing` exists, use that location.
- Use the old default location.

This logic is used on non-Windows, non-Mac platforms only. On Windows
and Mac the logic is unchanged.

Bugfixes:

- #3808: gui: Number of days must be number flashes red then disappears
- #5809: stdiscosrv failed to load keypair without proper error message
- #6410: Wrong 30-days-interval in staggered versioning
- #6430: Incorrect out-of-sync/locally changed status indication on folders
- #6436: Revert Local Changes red button does not work correctly
- #6440: Doesn't run monitor process when started with STNORESTART=1
- #6450: LDAP auth doesn't handle LDAPS with certificate validation
- #6487: Scan problem within single unignored subdirectory prevents bidirectional sync

Enhancements:

- #4924: Move index db to $XDG_DATA_HOME/syncthing/
- #5376: Improve LDAP authentication
- #6384: Do auto upgrades early and synchronously on startup
- #6416: Improve device status for "unused" devices
- #6432: Deleted file that existed locally only reported as locally changed
- #6437: Don't start browser when restarting after upgrade

Other issues:

- #6471: Windows exe isn't properly version tagged

v1.5.0-rc.2

This release changes the default location for the index database under
some circumstances. Two new flags can also be used to affect the
location of the configuration (`-config`) and database (`-data`)
separately. The old `-home` flag is equivalent to setting both of these
to the same directory. When no flags are given the following logic is
used to determine the data location:

- If a database exists in the old default location, that location is
  still used. This means existing installations are not affected by this
  change.
- If `$XDG_DATA_HOME` is set, use `$XDG_DATA_HOME/syncthing`.
- If `~/.local/share/syncthing` exists, use that location.
- Use the old default location.

This logic is used on non-Windows, non-Mac platforms only. On Windows
and Mac the logic is unchanged.

Bugfixes:

- #3808: gui: Number of days must be number flashes red then disappears
- #5809: stdiscosrv failed to load keypair without proper error message
- #6410: Wrong 30-days-interval in staggered versioning
- #6430: Incorrect out-of-sync/locally changed status indication on folders
- #6436: Revert Local Changes red button does not work correctly
- #6440: Doesn't run monitor process when started with STNORESTART=1
- #6450: LDAP auth doesn't handle LDAPS with certificate validation
- #6487: Scan problem within single unignored subdirectory prevents bidirectional sync

Enhancements:

- #4924: Move index db to $XDG_DATA_HOME/syncthing/
- #5376: Improve LDAP authentication
- #6384: Do auto upgrades early and synchronously on startup
- #6416: Improve device status for "unused" devices
- #6432: Deleted file that existed locally only reported as locally changed
- #6437: Don't start browser when restarting after upgrade

Other issues:

- #6471: Windows exe isn't properly version tagged

v1.5.0

This release changes the default location for the index database under
some circumstances. Two new flags can also be used to affect the
location of the configuration (`-config`) and database (`-data`)
separately. The old `-home` flag is equivalent to setting both of these
to the same directory. When no flags are given the following logic is
used to determine the data location:

- If a database exists in the old default location, that location is
  still used. This means existing installations are not affected by this
  change.
- If `$XDG_DATA_HOME` is set, use `$XDG_DATA_HOME/syncthing`.
- If `~/.local/share/syncthing` exists, use that location.
- Use the old default location.

This logic is used on non-Windows, non-Mac platforms only. On Windows
and Mac the logic is unchanged.

Bugfixes:

- #3808: gui: Number of days must be number flashes red then disappears
- #5809: stdiscosrv failed to load keypair without proper error message
- #6410: Wrong 30-days-interval in staggered versioning
- #6430: Incorrect out-of-sync/locally changed status indication on folders
- #6436: Revert Local Changes red button does not work correctly
- #6440: Doesn't run monitor process when started with STNORESTART=1
- #6450: LDAP auth doesn't handle LDAPS with certificate validation
- #6487: Scan problem within single unignored subdirectory prevents bidirectional sync

Enhancements:

- #4924: Move index db to $XDG_DATA_HOME/syncthing/
- #5376: Improve LDAP authentication
- #6384: Do auto upgrades early and synchronously on startup
- #6416: Improve device status for "unused" devices
- #6432: Deleted file that existed locally only reported as locally changed
- #6437: Don't start browser when restarting after upgrade

Other issues:

- #6471: Windows exe isn't properly version tagged

v1.4.2

This is a tiny update to fix a couple of crashes that should not have
landed in 1.4.1, and revert a change to the upgrade code that puts
unnecessary load on the upgrade server.

Bugfixes:

- #6499: panic: nil pointer dereference in usage reporting

v1.4.2-rc.1

This is a tiny update to fix a couple of crashes that should not have
landed in 1.4.1, and revert a change to the upgrade code that puts
unnecessary load on the upgrade server.

Bugfixes:

- #6499: panic: nil pointer dereference in usage reporting

v1.4.1

This is a regularly scheduled patch release.

Bugfixes:

- #6289: "general SOCKS server failure" since syncthing 1.3.3
- #6365: Connection errors not shown in GUI
- #6415: Loop in database migration "folder db index missing" after upgrade to v1.4.0
- #6422: "fatal error: runtime: out of memory" during database migration on QNAP NAS

Enhancements:

- #5380: gui: Display folder/device name in modal
- #5979: UNIX socket permission bits
- #6384: Do auto upgrades early and synchronously on startup

Other issues:

- #6249: Remove unnecessary RAM/CPU stats from GUI

v1.4.1-rc.3

This is a release candidate for the v1.4.1 patch release.

Bugfixes:

- #6289: "general SOCKS server failure" since syncthing 1.3.3
- #6365: Connection errors not shown in GUI
- #6415: Loop in database migration "folder db index missing" after upgrade to v1.4.0
- #6422: "fatal error: runtime: out of memory" during database migration on QNAP NAS

Enhancements:

- #5380: gui: Display folder/device name in modal
- #5979: UNIX socket permission bits
- #6384: Do auto upgrades early and synchronously on startup

Other issues:

- #6249: Remove unnecessary RAM/CPU stats from GUI

v1.4.1-rc.2

This is a release candidate for the v1.4.1 patch release.

Bugfixes:

- #6289: "general SOCKS server failure" since syncthing 1.3.3
- #6365: Connection errors not shown in GUI
- #6415: Loop in database migration "folder db index missing" after upgrade to v1.4.0
- #6422: "fatal error: runtime: out of memory" during database migration on QNAP NAS

Enhancements:

- #5380: gui: Display folder/device name in modal
- #5979: UNIX socket permission bits
- #6384: Do auto upgrades early and synchronously on startup

Other issues:

- #6249: Remove unnecessary RAM/CPU stats from GUI

v1.4.1-rc.1

This is a release candidate for the v1.4.1 patch release.

Bugfixes:

- #6289: "general SOCKS server failure" since syncthing 1.3.3
- #6365: Connection errors not shown in GUI
- #6415: Loop in database migration "folder db index missing" after upgrade to v1.4.0
- #6422: "fatal error: runtime: out of memory" during database migration on QNAP NAS

Enhancements:

- #5380: gui: Display folder/device name in modal
- #5979: UNIX socket permission bits
- #6384: Do auto upgrades early and synchronously on startup

Other issues:

- #6249: Remove unnecessary RAM/CPU stats from GUI

v1.4.0

This is a regularly scheduled minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.11

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.10

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.10

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.9

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.8

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed
  due to incoming requests. This limits Syncthing's peak RAM usage when
  there are many connected devices all requesting file data. The default
  is 256 MiB.

- The config option maxConcurrentScans has been removed and replaced a
  new config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with
  -no-restart should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration
  plus compaction at first startup after the upgrade.

Bugfixes:

- #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
- #5952: panic: Should never get a deleted file as needed when we don't have it
- #6281: Progress emitter uses 100% CPU
- #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
- #6304: Syncing issues, database missing sequence entries
- #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

- #5786: Consider always running the monitor process
- #5898: Database performance: reduce duplication
- #5914: Limit folder concurrency to improve performance
- #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.7

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed due
  to incoming requests. This limits Syncthing's peak RAM usage when there
  are many connected devices all requesting file data. The default is 256
  MiB.

- The config option maxConcurrentScans has been removed and replaced a new
  config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with -no-restart
  should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration plus
  compaction at first startup after the upgrade.

Bugfixes:

 - #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
 - #5952: panic: Should never get a deleted file as needed when we don't have it
 - #6281: Progress emitter uses 100% CPU
 - #6289: "general SOCKS server failure" since syncthing 1.3.3
 - #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
 - #6304: Syncing issues, database missing sequence entries
 - #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

 - #5786: Consider always running the monitor process
 - #5898: Database performance: reduce duplication
 - #5914: Limit folder concurrency to improve performance
 - #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.6

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed due
  to incoming requests. This limits Syncthing's peak RAM usage when there
  are many connected devices all requesting file data. The default is 256
  MiB.

- The config option maxConcurrentScans has been removed and replaced a new
  config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with -no-restart
  should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration plus
  compaction at first startup after the upgrade.

Bugfixes:

 - #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
 - #5952: panic: Should never get a deleted file as needed when we don't have it
 - #6281: Progress emitter uses 100% CPU
 - #6289: "general SOCKS server failure" since syncthing 1.3.3
 - #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
 - #6304: Syncing issues, database missing sequence entries
 - #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

 - #5786: Consider always running the monitor process
 - #5898: Database performance: reduce duplication
 - #5914: Limit folder concurrency to improve performance
 - #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.5

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed due
  to incoming requests. This limits Syncthing's peak RAM usage when there
  are many connected devices all requesting file data. The default is 256
  MiB.

- The config option maxConcurrentScans has been removed and replaced a new
  config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with -no-restart
  should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration plus
  compaction at first startup after the upgrade.

Bugfixes:

 - #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
 - #5952: panic: Should never get a deleted file as needed when we don't have it
 - #6281: Progress emitter uses 100% CPU
 - #6289: "general SOCKS server failure" since syncthing 1.3.3
 - #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
 - #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

 - #5786: Consider always running the monitor process
 - #5898: Database performance: reduce duplication
 - #5914: Limit folder concurrency to improve performance
 - #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.4

This is a release candidate for the v1.4.0 minor release.

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed due
  to incoming requests. This limits Syncthing's peak RAM usage when there
  are many connected devices all requesting file data. The default is 256
  MiB.

- The config option maxConcurrentScans has been removed and replaced a new
  config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with -no-restart
  should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration plus
  compaction at first startup after the upgrade.

Bugfixes:

 - #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
 - #5952: panic: Should never get a deleted file as needed when we don't have it
 - #6281: Progress emitter uses 100% CPU
 - #6289: "general SOCKS server failure" since syncthing 1.3.3
 - #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0
 - #6335: Crash or hard shutdown can case database inconsistency, out of sync

Enhancements:

 - #5786: Consider always running the monitor process
 - #5898: Database performance: reduce duplication
 - #5914: Limit folder concurrency to improve performance
 - #6302: Avoid thundering herd issue by global request limiter

v1.4.0-rc.3

This is a release candidate for the v1.4.0 minor release.

Bugfixes:

 - #4774: Doesn't react to Ctrl-C when run in a subshell with -no-restart (Linux)
 - #5952: panic: Should never get a deleted file as needed when we don't have it
 - #6281: Progress emitter uses 100% CPU
 - #6289: "general SOCKS server failure" since syncthing 1.3.3
 - #6300: lib/ignore: panic: runtime error: index out of range [0] with length 0

Enhancements:

 - #5786: Consider always running the monitor process
 - #5898: Database performance: reduce duplication
 - #5914: Limit folder concurrency to improve performance
 - #6302: Avoid thundering herd issue by global request limiter

Important changes:

- A new config option maxConcurrentIncomingRequestKiB has been added to
  limit the maximum amount of request data being concurrently processed due
  to incoming requests. This limits Syncthing's peak RAM usage when there
  are many connected devices all requesting file data. The default is 256
  MiB.

- The config option maxConcurrentScans has been removed and replaced a new
  config option maxFolderConcurrency. In addition to just limiting
  concurrent scans it now also limits concurrent sync operations. The
  default is the number of available CPU threads ("GOMAXPROCS").

- Syncthing now always runs the monitor process, which previously was
  disabled with -no-restart. This facilitates crash reporting and makes
  logging behave more consistently. The observed behavior with -no-restart
  should be the same as before but the internals differ.

- The database schema has been improved and will result in a migration plus
  compaction at first startup after the upgrade.