Thanks for your hard work on this Jerry - I’m using the macOS wrapper very successfully on a number of systems!
Could I log a feature request: being able to add environment variables and arguments to the Syncthing launch command? I’d like to perform a reset-deltas on my installations - but I don’t know what launch command you currently issue, in order to launch it manually from Terminal without breaking everything. Is it just setting home to ~/Library/Application Support/Syncthing/ ?
Hi @Moisie sorry for the late reply, wasn’t checking the forum for some time. On first start the syncthing daemon is copied to its own folder so we don’t overwrite the syncthing executable which is shipped with the application bundle. It is located here:
jerry@Jerrys-iMac:[~]
> ls ~/Library/Application\ Support/Syncthing-macOS/syncthing
syncthing syncthing.old
When you start syncthing without arguments it automaticly searches in ~/Library/Application\ Support/Syncthing for the configuration and indexes. So if you need something special you should add some extra arguments. Currently it is not possible to inject environment variables or extra commandline arguments from the wrapper. It is hardcoded for now: https://github.com/syncthing/syncthing-macos/blob/develop/syncthing/DaemonProcess.swift#L56.
I’m not sure many people will every tweak the arguments. For power users they could also run their own syncthing instance and use the wrapper for connecting to it. It is now tightly coupled.
I’ve been using syncthing-macos for a couple of months, but today I realized that this client is probably not being maintained (not sure). The latest version is dated January 2019, and the syncthing executables within the application package (when you look into the contents in /Applications) are also dated January 2019. If I use the “Check for updates” button in the About dialog, this client says that it’s the latest (version 1.0.0-2).
Further edits after a little more research:
Does this client download the latest syncthing binary and store it in ~/Library/Application Support/Syncthing-macOS? If yes, what are the syncthing executables within this application package in /Applications?
I think this client could avoid confusion (like mine) if it also listed the underlying syncthing binary version in the About dialog.
Is the underlying Syncthing version not sufficiently obvious from the version reported in the Syncthing GUI?
The application in /Applications is just a wrapper, to present the menu bar icon etc. This hasn’t needed to be updated to maintain compatibility with the Syncthing binary, which is stored in ~/Library/Application Support/Syncthing-macOS, hence why it hasn’t been updated in some time.
This was quite easy for me to miss in the browser while I was focusing on the upload/download rates, which folders were syncing (I have several individual ones) and how much data was being synced.
I understand that it’s a wrapper, and also get that it doesn’t need any updates to keep up with the syncthing application changes. Before I got to know where the syncthing binary was stored (under ~/Library), when I was digging into the application package, I saw that there are two “syncthing” binaries within the package. One is “Contents/MacOS/Syncthing” (note the uppercase “S”), which is the GUI wrapper that shows the menu bar icon and works with syncthing. The other is “Contents/Resources/syncthing/syncthing” (note the lowercase “s”). Both were dated January 2019.
I think there is scope for improvement in this wrapper and make it more user friendly (especially to cater to users like me who get confused):
Include the underlying syncthing version in the About dialog, or even better, in the menu itself if feasible. The browser GUI may not necessarily be opened by the user (and is not required to be opened except to monitor things).
Have some indication of when it updates the underlying syncthing binary (seems like it checks for updates on every launch, but if that’s the case, why is there a “Check for updates” button for this wrapper in the About dialog? Does this wrapper autoupdate itself on launch?).
I think the check for updates is to check for updates to the wrapper itself. But then the very fact that I’m not certain probably indicates that there’s scope for making it clearer to end users…
The Syncthing for macOS bundle will now only use the embedded syncthing daemon resource and will not auto-update the daemon since the new release v1.7.0-1 which is coming soon. Because I do it in my free time it was indeed true the bundle got not updated in a long time and people having issues.
As soon as the release is out I will post a message here.
What about syncing package file with Syncthing. I’m using scrivener and the scrivener projects are package files (they appear as a file but when right clicking on show package content we can access a folder tree). What if a file within the package is changed ? Does it sync the whole package « file » or only the changed file in the package?
Scrivener (Literature and latte) explains that dropbox is good but not iCloud (see Using Scrivener with Cloud-Sync Services / Cloud Syncing / Knowledge Base - Literature and Latte Support )
And Scrivener is not the only one using packages, Final Cut Pro is also using it
A “package” in this case is just a directory with files in it, that Finder treats specially for display purposes. Syncthing sees into it and syncs the individual items inside, for better or worse.
13:56:50 -- Codesign with Developer ID Application: Jakob Borg (LQE5SYM783)
13:56:50 Developer ID Application: Jakob Borg (LQE5SYM783): no identity found
13:56:50 Command PhaseScriptExecution failed with a nonzero exit code
13:56:50
Thanks @calmh it seems to work. But for some odd reason the appcast.xml CI/CD server (teamcity) deployer seems to run and generate the correct appcast.xml and latest release is added. But when I curl to the upgrade URL it is not deployed to the upgrade server. Odd… are you using some sort of cron job to copy the file to the webserver? I’m expecting the v1.22.2-1 as latest.
This is the curl:
jerry@coconut syncthing-macos % curl https://upgrades.syncthing.net/syncthing-macos/appcast.xml | head -20
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 18142 0 18142 <?xml version="1.0" encoding="UTF-8"?>:-- --:--:-- 0
<rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle" xmlns:dc="http://purl.org/dc/elements/1.1/">
0 <channel>
<title>Syncthing for macOS</title>
<link>https://upgrades.syncthing.net/syncthing-macos/appcast.xml</link>
<description>Most recent changes with links to updates.</description>
<language>en</language>
0 <item>
<title>Upgrade syncthing to v1.22.1 </title>
<description><![CDATA[<ul>
8<li>Update the bundled syncthing to <a href="https://github.com/syncthing/syncthing/releases/tag/v1.22.1">v1.22.1</a></li>
5</ul>
Latest build has the v1.22.2-1 with timestamp Fri, 09 Dec 2022 21:53:24 UTC
Here is the build artifact Log in to TeamCity — TeamCity
@calmh the problem still exists with the Syncthing for macOS after trying to create a upgrade package to v1.23.0-1. Whats going on with the infrastructure?
jb@ok:~ % curl -s https://upgrades.syncthing.net/syncthing-macos/appcast.xml | grep title | head
<title>Syncthing for macOS</title>
<title>Upgrade syncthing to v1.23.0</title>
There’s a 15 min cache in the HTTP proxy, perhaps that’s what you’re seeing, if you’re impatient.