This is an actual release candidate for 2.0. You might as well test it, otherwise you’ll just get the same bugs in 2.0-actual instead.
Major changes
Database backend switched from LevelDB to SQLite. There is a migration on first launch which can be lengthy for larger setups. The new database is easier to understand and maintain and, hopefully, less buggy.
Deleted items are no longer kept forever in the database, instead they are forgotten after six months. If your use case require deletes to take effect after more than a six month delay, set the --db-delete-retention-interval command line option or corresponding environment variable to zero, or a longer time interval of your choosing.
Modernised command line options parsing. Old single-dash long options are no longer supported, e.g. -home must be given as --home. All serve options are now also accepted as environment variables.
Rolling hash detection of shifted data is no longer supported as this effectively never helped. Instead, scanning and syncing is faster and more efficient without it.
A “default folder” is no longer created on first startup.
Debian packages
deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing v2
The mechanism warrants more of a write-up, yeah, but the short of it is that if you have devices that are offline for a longer period than this they will not be told of the delete when they come back, as other devices will have forgotten about it by then.
I wonder if this cleanup period could be dynamically created based on the list of devices and the last seen/sync date.
I.e. when the oldest device connects (or is removed) then it’s okay to purge entries up to the date of the next oldest device. (It may not be able to use the “last seen” date, but the date of the last successful transfer of the critical info like the file list)
Hi, I want to know how can I set the --db-delete-retention-interval command line option?
If I want the deleted items keep 2 weeks, set start command as below:
For 14 days, set --db-delete-retention-interval=336h
Technically, this is a Go time.Duration string, which:
is a possibly signed sequence of decimal numbers, each with optional fraction and a unit suffix, such as “300ms”, “-1.5h” or “2h45m”. Valid time units are “ns”, “us” (or “µs”), “ms”, “s”, “m”, “h”.
Tried to use it on a raspberry pi 1, only get “Illegal instruction” when trying to execute the binary. OS is raspbian bullseye with kernel Linux raspberrypi 6.1.21+ #1642 Mon Apr 3 17:19:14 BST 2023 armv6l GNU/Linux.
Yeah sorry about that. There’s a C compiler in the mix now as well and we’re running with essentially the defaults in terms of instruction set. I suppose that is something newer than armv6.
Yeah, for 32-bit arm go’s cgo compiler will simply set gcc -marm without specifying an actual architecture. This results in the gcc compiler assuming defaults, which is probably armv7 without floating point support. (Though I haven’t checked the gcc code what their actual default currently is).
It doesn’t look like one is allowed to override this. While you can tell cgo to pass along additional flags to gcc/clang, the list of flags is restricted and doesn’t seem to allow you to pass along the extra -march=armXYZ you would need to support armv6. I find that a bit strange, because the go compiler itself has several flags to tune its ARM code (e.g. GOARM={5,6,7} which is apparently not honored at all by cgo? Meaning that setting GOARM=5 still produces armv7 binaries with cgo enabled?
(It does the proper thing for MIPS: There it actually checks the subvariant and adjusts gcc accordingly, but they didn’t care about ARM < 8?)
Note our build process uses zig but I’m sure similar things apply. Also while we used to set down GOARM and GO386 etc I removed that as I didn’t see how it worked with the C parts. If we can do something more intelligent that’s welcome.
Building on the pi 1 itself worked and I got a working binary syncthing v2.0.0-rc.16 "Hafnium Hornet" (go1.24.3 linux-arm) pi@raspberrypi 2025-05-21 19:11:09 UTC
Indeed, because a 1 minute retention interval is nonsensical. The minimum allowed is 24 hours. The cleanup happens as part of the periodic maintenance which runs by default every 8 hours.
