From 3962a237232473c20a44945a6c8ce8c930375360 Mon Sep 17 00:00:00 2001 From: Jakob Borg Date: Thu, 21 May 2026 10:15:18 +0200 Subject: [PATCH] fix(syncthing): properly upgrade via REST when Syncthing is running (fixes #10697) (#10699) The locking logic for upgrades got inverted in the lockfile changes. If we got the lock it means Syncthing wasn't already running, so we can do a direct upgrade. If we failed to get the lock it means Syncthing was running and we should tell the REST interface to do the upgrade. Signed-off-by: Jakob Borg --- cmd/syncthing/main.go | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/cmd/syncthing/main.go b/cmd/syncthing/main.go index 8b29fdc0d..bd35c6667 100644 --- a/cmd/syncthing/main.go +++ b/cmd/syncthing/main.go @@ -915,10 +915,14 @@ func (u upgradeCmd) Run() error { case err != nil && !os.IsNotExist(err): slog.Error("Failed to lock for upgrade", slogutil.Error(err)) os.Exit(1) - case locked: - err = upgradeViaRest() - default: + case locked || os.IsNotExist(err): + // We got the lock, or the config directory didn't exist, so we + // can do a direct upgrade err = upgrade.To(release) + default: + // We didn't get the lock, because Syncthing was running, so + // upgrade via REST. + err = upgradeViaRest() } } if err != nil {