Syncthing v0.11.0 Release Notes

Upgrade Notes

:bangbang: Syncthing v0.11 does not support synchronizing with older versions (v0.10 or older).

When a connection is established between a v0.11 device and a v0.10 device, an error will be printed to the console and the connection is closed. This means you need to upgrade a cluster of devices together.

:bangbang: Syncthing v0.11 will rehash all files on first startup.

The database format has changed on disk and is not easily convertible. The database is written to a new name, index-v0.11.0.db in the configuration directory. The old database, index, will be removed approximately two weeks after it was last written to. This means there is a window during which a downgrade without reindex is possible.

:bangbang: Syncthing v0.11 requires updates to other programs it integrates with. If you use syncthing-inotify, syncthing-cli, SyncTrayzor, syncthing-gtk, metro.thing or other integrations, you will need to ensure that these are compatible and most likely upgrade them as well.

For these reasons, Syncthing v0.10.x does not automatically upgrade to v0.11. You will need to press the button manually, run syncthing -upgrade from the terminal, or wait for an updated package from your distribution. This is to avoid surprising you with a partially upgraded cluster at an unwanted time. Syncthing v0.10 will however not receive further updates.

Important Changes and Improvements

Conflict Handling

Versioning now uses version vectors instead of plain integers. This means we get actual conflict detection (finally). In case of a conflict during syncing the conflicting file will be renamed from file.ext to file.sync-conflict-YYYMMDD-HHMMSS.ext (with the current date and time) so that it’s preserved.

CPU Usage Improvements

The GUI has been changed from polling for updates (causing high CPU usage in many circumstances) to listening for periodic status updates from the server side instead. There’s still a CPU hit to the GUI though; it requires the status update to be calculated on first load, and the periodic status updates are only calculated when there is a GUI connected. Making these calculations quicker and cheaper is work for the future.

In addition the garbage collection threshold has changed from 25% to 100% (the Go default). This reduces CPU usage and increases sync speed for large files, while using more RAM in the process. The old behavior can be retained (when lower RAM usage is preferred at the price of lower performance) by setting the environment variable GOGC:

$ GOGC=25 syncthing

(It can also be adjusted above 100 to further tweak the optimization in the other direction.)

Performance Improvements When Syncing Many Small Files or Very Large Ones

The database commit process has changed slightly to better accommodate handling lots and lots of small files. The results is a faster sync with lower CPU utilization.

There’s also a change to make scanning of many large files more efficient. This is most noticeable on the initial scan on folders containing movies and similar.

REST Interface Changes

The path structure is changed to be clearer and more logical. See REST Changes in v0.11 for details.

All keys in JSON objects are now lowerCamelCase, where there was previously a mix of lowerCamelCase and UpperCamelCase.

Event Interface Changes

  • Two new events FolderSummary and FolderCompletion are now emitted when the underlying data has changed. Listen to these instead of polling /rest/db/status and /rest/db/completion.

  • The LocalIndexUpdated event is now emitted not for each file, but for each commit phase. A commit phase is up to 1000 files or two seconds long.

  • The ItemStarted and ItemFinished events have been made more streamlined.

External Versioning

A new, versatile “external” versioning scheme has been added. This uses a script or program provided by the user to the versioning.

Various UI Tweaks

The user interface contains a number of improvements. Language can now be selected directly in the UI, the process uptime is visible, and files are loaded quicker with lower memory requirements due to gzip compression.

Windows Long Filename Support

On Windows, extended-length paths are used to avoid the dreaded “file name too long” errors.

Stopped Folders are Restarted

Folders that have experienced an error (partition not mounted, for example) are automatically started again when they become available.

14 Likes

That’s great, many thanks.

Any idea for the release dates from the other developers (about the Android App and synthing-inotify) ?

There’s now a release candidate out. That’s v0.11.0 unless someone screams loudly soon. :slight_smile:

I updated all my nodes to it, and only noticed one oddity - a folder which I deleted a while ago reappeared. I don’t have enough information to bug report it.

1 Like

I’m releasing this into the wild now. :slight_smile:

4 Likes

I moved 3 posts to a new topic: Duplicate device ID on new install?

just installed 0.11 on 5 PCs (win/linux/arm-rpi). no issues at all. am waiting for the android app to update as well and i’ll be more than happy. i got to syncthing after using btsync. simplicity and opensource convinced me. kudos to you all!

Working fine for me as well! Congrats on a great release. I appreciate the vector clocks. :+1:

Just a note: connected devices will get stuck at 50% sync until you click the “Override Changes” button for each read-only folder on the master. I’m not sure if you had noted this somewhere or not.

Thanks for all the hard work! Just updated and so far, all is good. :smile:

Only a small note, on the wiki, the /rest/db/scan still uses the old format (without the “db/”) in the example:

1 Like

I moved 11 posts to a new topic: Web interface error (forbidden?)