Currently away from (Windows) keyboard, so I can’t test anything. But just today I navigated to the AppData\Local directory on my German Windows 10 installation. It’s there under a non-localized name for sure.
1 Like
When you are on German Windows, can you please run the below script (save as GetConfigPaths.js somewhere):
// GetConfigPaths.js
var ssfLOCALAPPDATA = 28;
var ssfWINDOWS = 36;
var FSO = new ActiveXObject("Scripting.FileSystemObject");
var ShellApp = new ActiveXObject("Shell.Application");
var WshShell = new ActiveXObject("WScript.Shell");
var LOCALSERVICE_PROFILE_PATH = "ServiceProfiles\\LocalService";
var CurrentUserAppDataPath = ShellApp.NameSpace(ssfLOCALAPPDATA).Self.Path;
var LocalizedAppDataPath = FSO.BuildPath(FSO.GetFileName(FSO.GetParentFolderName(CurrentUserAppDataPath)),FSO.GetFileName(CurrentUserAppDataPath));
var LocalServiceAppDataPath = FSO.BuildPath(FSO.BuildPath(ShellApp.NameSpace(ssfWINDOWS).Self.Path,LOCALSERVICE_PROFILE_PATH),LocalizedAppDataPath);
function main() {
var configDirAllUsers = FSO.BuildPath(LocalServiceAppDataPath,"Syncthing");
var configDirCurrentUser = FSO.BuildPath(CurrentUserAppDataPath,"Syncthing");
WshShell.Popup("All users:\n\n" + configDirAllUsers + "\n\n"
+ "Current user:\n\n" + configDirCurrentUser,0,WScript.ScriptName,0);
}
WScript.Quit(main());
Can you run above script on German Windows and report results?
Thanks!
Bill
1 Like
Not OP but also German:
1 Like
Thanks for testing that!
From an elevated PowerShell window (run as administrator), can you run this command:
Get-Item C:\Windows\ServiceProfiles\LocalService\AppData\Local
Please run above and post results?
Thanks!
Bill
1 Like
C:\Users\>USER<\AppData\Local
1 Like
C:\WINDOWS\system32> Get-Item C:\Windows\ServiceProfiles\LocalService\AppData\Local
Verzeichnis: C:\Windows\ServiceProfiles\LocalService\AppData
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10.07.2020 22:20 Local
1 Like
From these outputs it looks like SystemRoot\ServiceProfiles\LocalService\AppData\Local\Syncthing should work regardless of language.
Thanks for testing!
1 Like
1 Like
PS C:\WINDOWS\system32> Get-Item C:\Windows\ServiceProfiles\LocalService\AppData\Local
Verzeichnis: C:\Windows\ServiceProfiles\LocalService\AppData
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 25.03.2021 06:29 Local
1 Like
Thank you – it looks like non-English Windows also uses same path as English (SystemRoot\ServiceProfiles\LocalService\AppData\Local) for local app data path for LOCAL SERVICE account (SID S-1-5-19) - so we should be good to go.
Thanks for testing!
1 Like
I see the issue now - when we call generate for LOCAL SERVICE account, we aren’t copying generated config to correct directory (sorry about missing that step!). I will update the script and release a new installer package with the fix. Thanks for the report!
1 Like
Just a quick thought but would it make sense to add an (optional) Windows Defender exclusion for Syncthings database?
1 Like
I don’t think so…this would add a lot of overhead for little benefit, as I see it.
1 Like
Updated installer has been published to GitHub. (This fixes the bug where the config.xml file is missing when installing the Windows service.)
1 Like
Now the installation runs to the final and 2 Syncthing folders are created
C:\Users\>USER<\AppData\Local\Syncthing
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Syncthing
each with the items
cert.pem
config.xml
key.pem
Finally, I doesnt find the database. Next point is, if I modify anything, normally the config.xml is changed, but the above mentioned are not modified. Doe you have any idea?
There must be a place for that all, is unknown for me.
1 Like
The behavior you are seeing is correct - at install time, Setup creates the initial config for the current user (because there’s no other place to create it) and then copies it over to the service config. When you start the service, Syncthing will create the database, etc.
1 Like
Unfortunately, it doesn’t seem so easy.
After the installation the service starts and Syncthing runs as usual. Unfortunately, no database is created in the above mentioned locations, and nothing else can be found on the entire hard drive.
Since I have reported about it before, I assume that my computer maybe is infected from the previous installation and is still managing the data somewhere in the database, in a location I cannot find. Because apart from the two directories, I was able to open the GUI with all the settings from that older installations.
The only question is, where is that? Then I would uninstall and delete everything again. I suspect an encrypted folder or something like that. I had even thought that my virus scanner Avast would manage it in a sandbox - mind game.
Are there any registry entries that can indicate this?
1 Like
From your comments before it sounded like you were using a different installer to run Syncthing, in which case I don’t know where those files might be located. On my system the database is located in a folder C:\Windows\ServiceProfiles\LocalService\AppData\Local\Syncthing\index-v0.14.0.db and there are some .ldb files in that directory.
Syncthing doesn’t put anything in the registry. It uses the LOCALAPPDATA directory (for whatever user starts Syncthing) and by default places a Syncthing directory in there for its files. One reason the directory might be different is if the command line that starts Syncthing specifies a different path (e.g., --home).
1 Like
No, I´m use your first installer v1.18.6 but this one was still faulty. Because of this, I think that installion is now misleading the newer install v2 as well.
1 Like
If you initially installed with 1.18.5 installer you will want to uninstall that before installing 1.18.6. But other than that a reinstall worked fine for me in all of my testing. Without a detailed problem report that details specific symptoms it is hard to know what the problem is.
1 Like