@Andy I’ve created a new Syncthing instance for testing purposes without the MSI. It shows this DB content “as raw”.
So the upgrade info is somehow present in the DB, but I think that is for coordinating schema upgrades and not relevant to your problem described above.
It could at least explain the behavior as observed. Nevertheless, it would not be entirely plausible because after the installation I exchanged the complete settings directory together with the database for the previous version in which the automatic upgrade was activated.
That’s why I came across the registry, as it was independent of it. But it also seems to me that there are other entries of STNOUPGRADE besides
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\The Syncthing Authors\Syncthing
I found e.g.
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\ Environment
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
I don’t know if they have any influence. However, it appears to be typically backup entries from Windows.
Maybe you could do it differently. By definition, an MSI is an installer package with no optional features. Wouldn’t it make more sense to make an EXE in which various installation options can be selected?
This is your Windows environment. E.g. run “systempropertiesadvanced.exe” from the start menu, you can click the last button “environment variables” on the dialog to edit them manually without requiring REGEDIT. Remove STNOUPGRADE “plus” a config.xml where upgrades are enabled and you’re good to go.
The database records the schema version and minimum version required to open it, as Catfriend1 guessed. It does not store anything at all related to enabling or disabling upgrades.
On my Windows systems the MSI package is installed in
C:\Server\Syncthing\
and the database are in the subfolder there
C:\Server\Syncthing\AppData\index-v0.14.0.db
If I want to run a CLI command, e.g.
C:\Server\Syncthing\syncthing.exe -reset-deltas
not the above data folder is used, instead a folder from the official version is used
C:\Users\>user<\AppData\Local\Syncthing\index-v0.14.0.db
What is instead the right command to run syncthing.exe -reset-deltas?
Same way as you otherwise start it, just adding -reset-deltas if that’s what you want.
I need to check this to be sure… Normally the MSI sets up Syncthing to run under the LocalService account. You could try adding the “config dir” (see docs for exact param name) switch to point at the c:/server/syncthing/appdata directory and ensure your administrative (or user) command prompt has access to this directory by setting NTFS ACL accordingly. I should maybe bundle a batch script to do this so one in the need of this does not have to know all this background.
@Andy I’ve made a maintenance batch called “syncthing_cli.cmd”, bundled in the next MSI release.
Here’s a screenshot how to use it, I think it’s pretty self-explanatory. For nice look, I’ve also added a logtail so you can see whats going on with Syncthing running under LocalService. This way, running Syncthing.exe as LocalService (just as nssm would do it) for one time shot CLI commands, you don’t need to bother with granting permissions to Syncthing’s config directory. If you’d like to exit the one-shot, please go to Syncthing’s Web UI and choose Actions > Shutdown.
From administrative command prompt:
C:\Server\Syncthing>syncthing_cli.cmd --reset-deltas
2021-05-18_11:04:02: [INFO] regQueryToVar: Got SERVICE_ACCOUNT=[NT AUTHORITY\LOCALSERVICE]
2021-05-18_11:04:02: [INFO] Stopping service: Syncthing
2021-05-18_11:04:02: [INFO] Stopping process: syncthing.exe
2021-05-18_11:04:02: [NT AUTHORITY\LOCALSERVICE] Exec via task scheduler: syncthing --reset-deltas
ERFOLGREICH: Die geplante Aufgabe "Syncthing" wurde erfolgreich erstellt.
ERFOLGREICH: Es wurde versucht, die geplante Aufgabe "Syncthing" auszuführen.
2021-05-18_11:04:02: [INFO] Waiting for task to finish ...
A window with the log pops up (which is NOT syncthing.exe but powershell):
As you can see, the command “–reset-deltas” was picked up, see log row “INFO: Reinitialiazing delta index IDs”.
Now, I execute Actions > Shutdown.
EDIT: New release is up containing “syncthing_cli.cmd”.
First time I installed a modified version of MSI, that the package can run internal updates. If I install a newer version of MSI, such settings are lost or not?
If you directly modified the package with Orca, just modify it again. Basically, the first time setup routine will not run on upgrades so modifying the MSI is just necessary for new installations.
This issue brings me back to my request
as an “internal” feature to be platform independent. I have similar issues with Linux Mint and my Synology servers. Would that be possible to implement?
Maybe the same possibility here.
That possibility seems no longer to work
I installed Windows 11 and also a new MSI and I modified the newest MSI v1.18.2 with Orca, but I can´t set the update feature as known
Maybe is a better way to implement a feature I can chosse during installation.
Is a comment possible?
You should clarify what you are looking a comment on, given this thread is quite lenghty.
I’ll take a look, but currently I’m busy with some large deployment of something else. Maybe check if the setx env vars are set correctly on win11 by the installer!?
What is the correct setting and in which place?
Under win10 it is Systemproperties.exe (win+r key combination). there you will find advanced, environment variables to check if STNOUPGRADE has been set correctly. I hope it is the same for Win11, too (I don’t have it yet.)
Also, just in case, you can do Start → Run → rundll32.exe sysdm.cpl,EditEnvironmentVariables.
It works fine with Windows 11 as well. Otherwise I would have been surprised, the basis is Windows 10/8. The error was that I first had an installation with “STNOUPGRADE” = 1 and did not reinstall the MSI before using the MSI with “STNOUPGRADE” = 0.
