Status of Syncing without webgui

Hi, is there a possibility to get Status (which devices syncing which folders with percentage vs. idle) via commandline?

i found REST-Documentation, but not the status for all. /rest/db/status => folder status (how to enumerate folders) /rest/db/completion => folder status with device (how to enumerate folders/devices)

as i understand i can call REST via curl and make so a shell/webscript which is more faster than the full gui (laggy on some devices) or notify/shutdown after full sync.

regards Frank

All the info in the GUI is provided by the rest API, so everything is available as a rest call, you just need to find which onw or potentially do some computation to get the same value

The result of these API calls is in json format, which you can parse with Python for example. Or you can try syncthing-cli.

Be careful: syncthing-cli is basically unmaintained, and probably won’t work any more.

The main-problem i have is how to get the folder/device-ids…

Fetch the config and parse it.

i wrote a small php-script to get these data, not perfect, but if anybody search for that (post not tested/working):

got post also working, but only with GET-Params (POST to url?params)…bug in syncthing?

post-params should not be visible in url…tested with /rest/system/pause

if i use only post-params, it is not working

It’s a bad design decision that was made a while ago and is now near impossible to fix.

sorry, but imho it’s not a bad design decision, it’s simply wrong :slight_smile:

Parameter-Length of GET is limited by client, POST is limited by server. with GET you can run into problems within this Limitation (e.g. post config). Also programmers are confused like me if they make a post and post-params are not accepted…

i took a quick look to source, but did not found the definition of the Rest-Interface (which file(s)). i have no knowledge about go-language, but in other languages you can create a dual-stack for compatibility (to have time to fix frontends). simply check parameters from both methods…post (on post-functions) first, and if no data there, take get-params. currently the post-functions are not as much, and i assume you have 1 entry-function for the param-collection before calling the REST-function itself (using get/post there is also bad idea).

We are not putting config in a query string.

Something that was supposed to be (made up example)

POST /stats/(folder)/(file)


POST /stats?folder=(folder)&file=(file)

Yet the payload still goes in the post data, query strings are just used for routing the post request.

1 Like

Yeah, it’s not wrong by any objective criteria I think, but I can agree it would be cleaner to have done it as paths from the start.

It’s not exactly impossible to change (with a compatibility layer), if someone feels strongly about this.

1 Like

ok, it’s comprehensible, but then routing-data should also be taken from post (if available there) the documentation says nothing about GET-Params in POST-functions

The documentation has examples in most places. There are some methods that do not have examples and mention “parameters”. These are always query parameters.

There are no “get parameters” in HTTP, only the query string and the request body.

Depending on the actual code we may accept www-form-url-encoded body as well. Not tested, though, and only when no other body is explicitly expected.

No, I disagree. The URI (including query string) identifies the resource to be updated by the POST. The body of the request contains the updated resource.

POSTing to /db/override?folder=(folder) means “update the overrides resource for (folder)”. This makes sense.

POSTING to /db/override with the body folder=(folder) means “update the /db/override resource, and set it to folder=(folder)”. This doesn’t make sense. It implies that you’re replacing the /db/override resource, removing what was there before, and replacing it with “folder=(folder)”.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.