Hello! I am new to Syncthing. I have been really excited about using Syncthing to sync my Android Phone to my Windows 11 computer over wifi.
I installed the app on my Samsung Phone. I also installed the Syncthing program for 64 bit systems in Windows 11. I installed SyncTrayzor also.
Any time that I launch SyncTrayzor, it doesn’t work properly. Here is the error log:
[monitor] 09:15:42 INFO: Log output saved to file “C:\Users\Seth\AppData\Local\Syncthing\Syncthing.log”
[start] 09:15:42 INFO: Syncthing v1.18.1 “Fermium Flea” (go1.16.6 windows-amd64) teamcity@build.syncthing.net 2021-07-30 12:41:57 UTC
[start] 09:15:42 WARNING: Failed to initialize config: config file version (36) is newer than supported version (35). If this is expected, use -allow-newer-config to override.
I have tried killing all Syncthing processes, restarting my computer, reinstalling Syncthing, running windows update, making sure that NET framework is installed. Maybe I should try completely uninstalling, reinstalling and rebooting again?
Can anyone help me to get this running?
I tried reading through the FAQs, but could not readily find someone else with the same problem.
This is the problem here. You should choose either the basic Syncthing binary or SyncTrayzor. If you’re a new user, I would suggest SyncTrayzor.
If you haven’t configured anything yet, then you can simply delete the whole %LOCALAPPDATA%\Syncthing folder (copy and paste the path to Windows Explorer) and then try to start SyncTrayzor again.
The error message is peculiar though. I’ve had similar reports recently on the SynoCommunity package where Syncthing dies because of a future config version. But we had changed the behavior roughly one or two years ago, so that it tries to do an upgrade in this scenario instead of choking on the config version.
Apparently that behavior has changed again, so we need to investigate and I believe it could be a regression from previous releases.
In your case, yes it seems to be caused by installing Syncthing standalone first (which saves the most recent config version 36), then switching to SyncTrayzor which comes bundled with a slightly older Syncthing executable that still expects version 35. You could try to copy the downloaded Syncthing.exe file to the folder where SyncTrayzor tries to start it from, overwriting what is currently there. That should provide a quick fix. Sorry I don’t know the exact location right now, still on the train.
I don’t think we’ve ever had that behavior. In principle, if the config is from the future we can’t know what parts of it we understand and not, so we can’t know if we’re allowed to upgrade or not. (What we do have is something for betas/RC:s where we check for a newer beta/RC before doing other stuff, as these always have upgrades enabled, and we had some startup-blocking issue in some beta…)
This is sort of an inherent problem in packagings that a) bundle a Syncthing binary and b) allow Syncthing-only upgrades, since a reinstall of the “same” package will downgrade Syncthing… I generally recommend not doing that. Either bundle a non-upgrading binary or make sure to do the upgrade on install.
Thanks everyone! I uninstalled Syncthing, SyncTrazor, and the app on my phone. I reinstalled the app on my phone and just SyncTrazor. Everything appears to be working now. Thanks for your help!
I guess you’re right, it was about the database schema back then. Can’t find the exact PR, but it must have been somewhere around v1.4 time. So we were simply lucky that the config didn’t change as often or people just didn’t run into the issue.
Yes, but I think it’s a problem we need to deal with. It’s not only reinstalling, but also delayed package updates: Package v1 internally upgrades the bundled Syncthing v1 to v2, v3. A new package is rolled at v3, but the user doesn’t install it right away. Meanwhile Syncthing v4 and v5 come along, and by the time the user notices and installs the v3 packaging as an upgrade of the previous v1 packaging, that is effectively a downgrade of the bundled Syncthing from v5 to v3. The main reason why this cannot be easily avoided in the case of SynoCommunity for example is simply lack of time for people to validate and publish package updates regularly with only new upstream versions. It just doesn’t scale.
What’s the solution? Should we relax the check somewhat, as done with the DB? After all, the chosen XML format is designed to provide exactly that future-proof property on the syntax level. On the semantic level, the best we can do is to check the upgrade option known to the running version (<autoUpgradeIntervalH>), falling back to its default if it cannot be found. Whatever mechanism a newer version introduces in addition to prohibit upgrades can never make sense to any version that predates it. So we need to make extra sure the current option at least never gets removed. Or tell people who definitely want to prohibit upgrades to use another, forceful way independent from the config (compile time --no-upgrade and STNOUPGRADE).
Or should we just motivate bundling packagers (at least SyncTrayzor and SPK) to always specify --allow-newer-config because these situations can’t be avoided totally?
Lastly, such packagers could check on upgrades / reinstall if the existing Syncthing binary is newer than the one being unpacked and skip in that case. That’s error prone though and possibly not desirable because there is no longer a “clean reinstallation” path. And whether the binary is guaranteed to be retained together with the config and DB is questionable.
Right now packages could on install run syncthing serve --upgrade. Or detect the error and then do the same. It might also be sensible to do that “internally”, i.e. on startup if we detect a newer version, try to upgrade instead of failing immediately (might be a bit tricky to not keep repeating that if the upgrade doesn’t work).
Both these solutions should take into account when the user has opted to disable upgrades. That’s difficult with the external solution, because --upgrade overrides the interval = 0 config.
Trying to upgrade first when finding a future config version of course should be gated by the opt-out config. If we could find out the config version already, I’m sure it’s possible to read <autoUpgradeIntervalH> as well and abort before the upgrade if set to zero. That’s what I meant above. Only any hypothetic different opt-out mechanism from the future couldn’t be honored, but there’s no way to achieve that.
IMHO, a package that lets Syncthing upgrade separately is not a Syncthing package but an installer. It might then just as well discard all pretence of being related to the Syncthing version and just grab the latest from internet at install time. Getting a downgrade by doing a reinstall of a “package” is just broken.
Totally agree with Jakob: If an installer wants to handle this gracefully (and seems like it should), it can track the installed Syncthing version in some state of it’s own and on install check that and if the bundled Syncthing is newer than previously installed, act appropriately (just install that Syncthing version, ask user, … - entirely depends on what the intent of the wrapper). Or as proposed before: You can also detect the “future config error” and take similar actions based on that.
That is just not practical under some circumstances. The Synology NAS boxes are a good example, as they may deliberately not have an internet connection at all. Relying on an internet download to work around a packaging bug is not a proper fix.
I’ll see what I can do for the SynoCommunity package. As long as --upgrade works regardless of config and database version, there should be a straightforward way to fix it.
SyncTrayzor should better also add some graceful error handling for this, @canton7?
While we’re at it, wouldn’t a syncthing upgrade [--check] subcommand be more sensible than the current syncthing [serve] --upgrade form? I’d volunteer to implement it, keeping the old flag for compatibility and eventual deprecation.
In an ideal world I’d release a new synctrayzor version every time Syncthing does an incompatible change to its database or config file, but in practice I’ve no idea when this happens, and new releases are somewhat on the back burner since I stopped using Syncthing.
The problem with just grabbing Syncthing at install time (other than the additional failure modes) is that I’d need to (want to?) duplicate Syncthing’s signature checking logic. I’d rather just let Syncthing handle downloading and verifying an update: it knows what it’s doing better than I do.
What’s the best way to handle this? How should I detect this error (does it have its own error code?), and what exactly should I run to force it to upgrade there and then?
Oh, sad to hear you’re not as much into Syncthing development anymore.
I think releasing a new SyncTrayzor frequently only partially fixes the problem. Who says a user won’t try to reinstall it from some old installer they still have lying around from last time? The fact that Syncthing updates itself (which is good) should at least be considered and lead to a meaningful error message or an automatic workaround instead of failing horribly. To handle it gracefully, we need to consider at least two situations:
Reinstallation with an up-to-date Syncthing binary still intact. We check the version of the binary and compare it to the one shipped with the installer package, before overwriting the former with the latter. Should be easy to do by calling each with the --version flag.
Installation without an existing binary, but leftover configuration folder. This one can only work with an internet connection obviously, but I agree that Syncthing itself should download and check the upgrade. We detect this by running the unpacked version and catching the “config from the future” error, which should be conveyed in a stable, machine-parseable form. Maybe syncthing --check-config or similar. Then we try syncthing --upgrade-check and if successful possibly ask the user for confirmation before running syncthing --upgrade. If the checking fails, we can only give a good explanation of how to fix it manually.
Note that for the Synology package, I probably won’t need to consider 2. On that platform, user data will always be removed as well when the syncthing binary is uninstalled.
I don’t need to worry about 1, as I never overwrite a user’s binary (and I’d struggle to find it anyway, as it could be anywhere!). I’ll also never downgrade Syncthing. What I do is:
See whether a copy of Syncthing exists in synctrayzor’s AppData folder.
If not, copy the binary which was bundled with the synctrayzor installer.
If so, leave it be.
This means every user of the system gets their own Syncthing binary.
To be honest, this means that downloading the latest Syncthing at install time doesn’t work for the general case: you still have the case where User A downloads and installs synctrayzor, time passes, user B downloads and runs the latest Syncthing, then runs the installed synctrayzor. Or indeed, a single user installed synctrayzor, forgets about it, then downloads a new Syncthing, runs it, then runs synctrayzor again.
I don’t think you need to do anything fancy or catch all the corner cases of people keeping secret stashes of old installers and separate binaries and whatnot.
If you’re installing a Syncthing that’s likely going to auto-upgrade, just make sure to run syncthing -upgrade once at install time to (attempt to) get the latest version at that point.
It may be likely to auto-upgrade, but disabled by user preference. If we unconditionally run syncthing --upgrade at that point, we forcefully overrule that preference. Either we do it only on detecting “config from the future”, or we add a best-effort --maybe-upgrade mode, which tries to honor the configuration preference (reading it as if --allow-newer-config was passed).
Or what about the easiest route to just always run with --allow-newer-config once after installation / upgrade in these setups?
You do it at install time – they haven’t made a choice yet, and since you’re not bundling a non-upgrading Syncthing your package/installer can’t make any promise about which version it’s going to install. If you consider a reinstall and are thinking about whether you have implicit or explicit permission to do an upgrade then given choices the user might have made previously, I’d say that the one thing you certainly aren’t expected to do is downgrade Syncthing.
The switch to allow newer config is an emergency escape hatch, don’t use it lightly. At the very least it’ll wipe out any newer config options the user had done prior to the downgrade.