Syncthing v0.14.49

Announce Release
1

v0.14.49

This is the somewhat delayed and larger than usual point-49 release.

Since the scheduled slipped the next RC release will be on Aug 7th, with the point-50 released for real on Sept 5 (barring fuckups).

Bugfixes

  • #4854: macOS panic in FS watcher setup
  • #4925: Deleted files within deleted directories aren’t detected with FS watcher
  • #4944: Edit Folder UI displays default “Full Rescan Interval (s)” value instead of the actual one
  • #4981: Race on folder restart
  • #4983: Impossible to edit folder with path “/”
  • #4990: Incorrect large block size chosen for large files on 32 bit archs
  • #4994: Database schema from the future should be rejected
  • #5002: v0.14.48 panic: runtime error: index out of range
  • #5017: “kiB” should be “KiB”
  • #5025: Stuck in CPU consuming accept loop when out of file descriptors
  • #5050: Filesystem watcher doesn’t notify changes on Windows when the file size remains the same

Enhancements

  • #4863: Snap package could use removable-media slot
  • #4953: Speed up delete propagation when it’s not a rename
  • #4969: Executable files edited on Windows should retain execute bit on Unixes
  • #4977: Disable rescan button while scanning instead of hiding it

Other issues

  • #4900: Replace deprecated github.com/kardianos/osext with standard library’s os
  • #5000: Snap build is broken
6 Likes
2

Excuse me, is this problem: Conflicts with version 0.14.48 resolved in this version or we have to wait for v0.14.50?

3

I don’t know, I didn’t understand the issue and I don’t think there was an issue filed on it apart from the PR that wasn’t merged.

4

AFAIK it’s supposed to be fixed in .49

As discussed in the linked thread and few related PRs, the issue was supposed be fixed as part of “local flags” enhancements, which eventually got merged into .49-RC-4, and now released as 49 stable.

That being said, I have yet to test it properly myself.

2 Likes
5

As @scienmind said: It’s most likely fixed, meaning in another thread a user with the same problem did test it and didn’t get those conflicts anymore. Also the reason why it happened was pretty clear, I’d be very surprised if it wasn’t the same for you.

1 Like
6

I’m trying to build from source downloaded from

https://github.com/syncthing/syncthing/releases/download/v0.14.49/syncthing-source-v0.14.49.tar.gz

in a temporary directory with

go run build.go -no-upgrade

which fails with

can't load package: package github.com/syncthing/syncthing/lib/auto: cannot find package "github.com/syncthing/syncthing/lib/auto" in any of:
        /usr/lib/go/src/github.com/syncthing/syncthing/lib/auto (from $GOROOT)
        /root/go/src/github.com/syncthing/syncthing/lib/auto (from $GOPATH)
can't load package: package github.com/syncthing/syncthing/cmd/strelaypoolsrv/auto: cannot find package "github.com/syncthing/syncthing/cmd/strelaypoolsrv/auto" in any of:
        /usr/lib/go/src/github.com/syncthing/syncthing/cmd/strelaypoolsrv/auto (from $GOROOT)
        /root/go/src/github.com/syncthing/syncthing/cmd/strelaypoolsrv/auto (from $GOPATH)

This built without problems up until 0.14.48

maybe commit ef5ca0c218cfd072860d2b06d63c3d36ddc63813 has something to do with it ?

7

I can confirm that. Easy workaround is to set GOPATH to the appropriate path. The generation of a temporary gopath happens after generating the assets. Now that the generation happens via go instead of custom scripts, that doesn’t work anymore in this order, as a valid GOPATH is already required.

8

Helped me too :slight_smile:

9

We’ll switch to using modules soon and then all this will break againwork perfectly.

3 Likes
10

https://github.com/syncthing/syncthing/pull/5093 did the trick.

Thanks!

11

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