I’ve been working on a Windows host for Syncthing, and would like to share. The goal is to make Syncthing behave a bit more like a native Windows application (in the same vein as Bittorrent Sync). This means:
Installation using an installer
Automatically start on login
Remove the need to open an external browser to interact with Syncthing. SyncTrayzor contains a built-in web browser, see the screenshot below.
Close to a tray icon, and can show ‘Finished Syncthing’ messages from the tray icon.
Folder watcher. This will watch your folders for changes, and alert Syncthing when it sees one. This means that changes can be picked up instantly by Syncthing, without having to wait for the polling interval to elapse. The folder watcher also honours Syncthing’s ignores, and won’t trigger for files that are being synchronized.
Wow, this is really cool! I just switched to it (I was using SyncthingTray before which I wanted to improve a bit, but now there’s no reason for me anymore) and I really like the portable mode which enables me to have all Syncthing related settings/files in one folder/place.
Just two small issues:
It would be nice to have bigger icons for the .exe so that shortcuts to it are looking sharp. I’m currently using my own .ico file which has all relevant sizes (up to 256 x 256) of Syncthing in it.
When I first started SyncTrayzor it created the settings of Syncthing in SyncTrayzorPortable\data\syncthing (like I expected it). I closed SyncTrazor, deleted this folder and copied the settings of my original Synthing installation to this place. After the next start I noticed that SyncTrayzor was not using the API key that was defined (by me) in SyncTrayzorPortable\data\syncthing\config.xml, but a different one. I’m not sure if this was a “default” API key or the one that SyncTrazor set during the first start, but I think it would be better to load the API key from Syncthing’s config.xml if there is one (or is SyncTrayzor already doing this?).
Apart from these two small issues I’m very happy with the program so far .
Good call on the icon. I have Windows set up to use small icons everywhere, so I didn’t notice the issue. If you’ve got a .ico file with the relevant sizes in already, would you mind throwing it my way? That will save me a bit of time.
SyncTrayzor overrides whatever API key Syncthing has in its config with its own key (which it specifies on the command line when starting Syncthing). This lets it talk to Syncthing without relying on parsing Syncthing’s configuration file (which I consider, rightly or wrongly, to be an implementation detail, so don’t want to rely on). You can set the API key that SyncTrayzor uses in File -> Settings: it auto-generated one for you to start with, but it’ll accept whatever you put in here.
I’ll document this - while I think SyncTrayzor does the sensible thing here, I agree that it’s not particularly obvious!
EDIT: Oh, and stop/start Syncthing if it’s already running (using the menu - or restart it from within Syncthing’s UI) after changing the API key
I created it using the official .svg file. The following sizes are included: 256 x 265, 128 x 128, 64 x 64, 48 x 48, 32 x 32, 24 x 24 and 16 x 16 in both 32- and 8-bit color (I’m not sure if the 8-bit versions are needed, I just read somewhere that these may be needed for older versions of Windows).
I haven’t looked at your code, but while I worked a bit on SyncthingTray (which also uses C# as programming language) I noticed that one has to set the .ico file with the large icons as “Icon” (under “Icon and manifest”) in the “Properties” of the project and a 16 x 16 version of the icon has to be set as the icon of the program window (“notifyIcon”). Otherwise the taskbar icon will look blurry as the program (or Windows) will choose a higher resolution of the icon which will then be downscaled. But I think you have much more experience with C# than me (I’m more familiar with Java), so this should be easy for you .
Regarding the other “issue”: I think your solution is just fine, I just wondered why there were different API keys in SyncTrayzor and in the config file of Syncthing. It seems that Syncthing doesn’t write the API key to the config file if it is passed as a parameter to the .exe, but this is just my guess (or it simply doesn’t overwrite an existing key?).
This works a treat on my desktops, lovely. But when I try to load on my Win8 Aspire 10 it says “This program can be installed on versions of Windows designed for the following processor architectures: x64”. My processor is an Intel Atom Z3735F. Any hope?
Thanks! I’ve included your icon, and updated all of the tray icons to contain 16x16 only (I’m not using WinForms, as SyncthingTray is, but Windows was still keen to choose the 32x32 icon if available). I’ll push out a new release shortly.
Yeah, it seems as though the command-line-supplied API key (and GUI host address) don’t affect the Syncthing config in any way (either in the config file or in the GUI). They just get used by Syncthing in preference to the key from the config. I think this is the right thing to do, although it is a bit unintuitive. Overwriting the config here would, I think, cause even more confusion!
I haven’t heard of
anyone using x86 in a very long time now. If you’re the exception, let
me know (open an issue) and I’ll start pushing out x86 builds.
So it seems that SyncTrayzor is compiled as x64 only.
@canton7: Would setting the platform to “Any CPU” be a solution here? As far as I know the .NET virtual machine picks the right version (x86 or x64) when this option is set. The only “problem” left would be to download the right version of Syncthing.
Aah Atom, of course. I’ll have a new version together for your shortly - hang tight.
Unfortunately not - the embedded browser component is unmanaged, so separate 32-bit and 64-bit builds are required. I’m in the process of getting that infrastructure together - I’ll have a new release out shortly.
@camsam I’ve just released v1.0.6, which contains a 32-bit build. Could you let me know if it works? No hurry - I’ve got to get up in 4 hours so I’m going to hit the sack.
Just migrated over from NSSM - absolutely brilliant! And I think the file watcher functionality sounds compelling.
As we are in the middle of a cataclysmic event with BT Sync, I think it might be an opportune time to advertise this prominently on the main syncthing page, to capture the Windows users. (As it is now, I think they have to dig around on a wiki and investigate several options, and I am afraid we might lose some people if they aren’t tech savvy enough.)
Any thoughts on supporting syncthing’s web GUI username/password? I created a feature request on github. I am thinking it may be nice to allow wrapper apps like this to log into the web GUI using the API Key (and a username of “APIKey” or something), so that they don’t have to store the web username/password.
I’ve replied on github, and opened an issue with Syncthing (#1420). If we can get some extra support in Syncthing for this, then fantastic. If not, we can just prompt the user.
EDIT: Fixed in code, will be in the next release (Monday? Tuesday? Sometime around then). I don’t want to release too often, as it causes a prompt to be raised for everyone who’s already installed it!
I have reservations about installing as a service. My take on it is that Syncthing is an inherently user-level application. It synchronizes the user’s files, with the user’s permissions, using configuration from the user’s AppData. It therefore needs to be run at the user, when the user logs in. Running it with elevated (LOCALADMIN) permissions is just asking for trouble in all sorts of places: file permissions, security - you’ve just opened an attack vector for people to edit previously-uneditable files, someone erroneously trying to sync Program Files or C:\Windows, etc. I’m not prepared to accept that level of responsibility. Configuration is another aspect: per-user configuration becomes nie-on impossible, unless I’ve missed a trick.
On the flip side, running a service as a particular user kind of defeats the point of services, and doesn’t support multi-user computers (only the user the service is running as will be able to use Syncthing).
I think the ‘Install Syncthing as a service with NSSM’ craze started because a service is the most obvious way to start an application when the computer starts, assuming the original proponent forget about start-on-login.
If you can explain why those reservations are mis-founded, then I’m open to the possibility of installing a service. However this would take a while: I’d need to support tray utilities that both ran everything in one process (for the portable users - there are a few of them), and one that could get all the data it needs from IPC with a windows service. Not impossible by any means, but give me a couple of months
Personally I completely agree with you.
I am just relaying all the craze in the previous months, people insisting that syncthing should run as service.
I think what people are really asking for it “I want to install Syncthing using an installer, and have it start automatically”. Marketing a start-on-login solution as just that may work? If that fails for the more stubborn, then a big list of reasons why a service is a Very Bad Idea (complete with little red crosses next to each bullet point, etc) may be in order!
EDIT: If it helps, Bittorrent Sync doesn’t run as a service either - or at least didn’t when I last used it.
@canton7 Thanks for your great work! I agree that a service is probably not the right tool for the job. Just go on doing it the way it’s done now and if someone makes an incredibly compelling argument, you can still think about it.
.