Syncthing v1.8.0


This release:

  • adds the experimental copyRangeMethod config on folders, for use on filesystems with copy-on-write support. Please see for details.

  • adds TCP hole punching, used to establish high performance TCP connections in certain NAT scenarios where only relay or QUIC connections could be used previously.

  • adds a configuration to file versioning for how often to run cleanup. This defaults to once an hour, but is configurable from very frequently to never.


  • #5425: Allow editing ignore patterns texterea in GUI’s folder dialog even when #include fails
  • #6733: strelaysrv can’t propely unmarshall a response when joining a pool
  • #6784: Remote device completion 100% while it is actually syncing
  • #6816: fatal error: concurrent map read and map write
  • #6823: Syncthing 1.7.0 performs UPnP with NAT traversal disabled
  • #6825: “pull: no such file” for existing untouched files


  • #4259: Attempt TCP hole punching
  • #4271: Make use of filesystems that can handle copies efficiently.
  • #6075: Feature: API check sync status of folder[s]
  • #6313: Improving disk access control in folders with file versioning
  • #6565: Create versioning directory recursively (creating parents as necessary)
  • #6795: Don’t warn encountering an invalid path separator for deleted items
  • #6807: “File Pull Order” should be disabled (greyed out) for “Send Only” folders in the GUI
  • #6832: Support running syncthing Docker image as non-root user

Also the relay server:

1 Like

AFAIK, this release also contains changes to the discovery server? Could we also see a release to that, please?

1 Like

I can sort that tomorrow, didn’t see it mentioned in the resolved issues so didn’t look closely.

Also discovery server:

1 Like

I’m very sorry because I don’t want to nag, but I can’t find the discovery & relay server binaries on

(Maybe that will sort out itself if updates are pulled periodically, otherwise take your time, it’s not urgent)

Yeah I should really automate those releases too… :confused:

How about now? :slight_smile:

1 Like

Thanks everybody who contributed!

1 Like

I have a question regarding the version naming scheme.

git checkout v1.7.0
git revert c7d6a6d78042876d9a27b13df2ae45783dca7c37
go run build.go -goos windows -no-upgrade -goarch amd64 zip


git checkout v1.8.0
git revert c7d6a6d78042876d9a27b13df2ae45783dca7c37
go run build.go -goos windows -no-upgrade -goarch amd64 zip


Am I doing something wrong, or has the scheme changed? Is the latter supposed to have v1.8.1-dev.1 in the name instead instead of v1.8.0+1? Just compiling from the tag with no additional commits does create a correctly named file

The scheme changed:

Thank you. I must admit that I got a little confused seeing the produced file, as I initially thought that I had compiled from main rather than one of the tags.

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