Status of folder with pending Revert Local Changes

Ref. issue Folder "Up To Date" but has pending "Revert Local Changes" · Issue #5968 · syncthing/syncthing · GitHub

To preface: I know Syncthing is not a backup solution :slight_smile:

I have a Receive-Only folder which has local changes and is displaying the “Revert Local Changes” button. Its status shows as “Up To Date”, so without expanding the folder in the GUI there’s no apparent need for attention for the folder. In this specific instance I know it will have been like this for 3-4 weeks.

I would expect that users need to know if a folder has pending changes to Revert, so perhaps the folder status should show something other than “Up To Date”. As discussed on the issue the folder is in fact up to date with the cluster, so there’s an argument that “Up To Date” is accurate.

In this specific instance this Receive folder receives files from another device and periodically backs them up. Spurious data here means that the backup is polluted (if I do a restore and there’s 1000 extra files, it’s a pain to deal with). If I was made aware that there are local changes, from the status line in the folder header, I would at least be aware that attention is needed.

Anyone else care to chime in?

1 Like

Something like “Up to Date (Local Changes)” would seem reasonable to me.


Translators hell. It would wrap over 9 lines in german

Just “Local Changes” with higher prio than “Up to Date” bot lower than “Out of Sync”?

1 Like

I guess, but then why not simply out of sync lets say?

I’ll quote you on that :wink:

It’s up to date in terms of the files that are advertised in the cluster, all of those files are in sync.

It’s not actually missing anything, it’s just containing some extraneous stuff. I can imagine someone setting a folder to receive-only to prevent cluttering the synced share, but not actually minding local changes, while going out-of-sync would still be problematic. However maybe I am imagining things :slight_smile:

I guess I am myself looking for the right answer here.

Local changes does not explain that the global state actually matches, as in the distinction between local changes and out of sync is not clear, and out of sync is somewhat correct but over dramatic.

I hoped to convey that by making out-of-sync overriding, i.e. if there are both out-of-sync items and locally changed ones, the status is out-of-sync. I don’t believe we need to make anything about matching global states explicit, as most users don’t care/understand. We just need a visual element when collapsed, that gives an indication that there is something off (local changes) regarding this folder. And I’d think that the added distinction to out-of-sync adds some value.

I think local changes is misleading tho, as it could be understood as local changes to global files, when it’s not, it’s just extra files, not actual local changes, especially when actual local changes result in out of sync…


Right. “Local Additions”? Or, given that we are just talking about additions to a receive-only folder, “Up to Date”…

1 Like

Imho, it either has to be out of sync or stay as it is I think.

It’s definitely not “out of sync”. I didn’t read/think properly at first, thinking this was about modifications to otherwise-synced files. Given that it isn’t, and that those files are in fact in sync, I’m good with “up to date”. I’d also be cool with something like “local additions” but I’m certainly not going to fight for it.

“Local Changes” sounds like the simplest idea; it would definitely stand out of the Up To Date crowd. Now can we start a fight on a colour? Must be time for some yellow…

I guess we’d have to document what that means as it’s super not clear what that means.

As I see it the issue with “up to date” is not that it’s incorrect in meaning, but that there is no indication in the web UI that there is something to revert. That’s why I’d be in favor of adding “local additions” (as “local changes” is misleading as explained above by Audrius). In terms of color I’d say stay the same as up-to-date, as it is up-to-date.


The folder type being what it is, Receive Only, I can’t see why Up to Date would suit when local addition(s) or change(s) happened. Please consider I only say “I can’t see” which I guess means I don’t understand the underlying prereqs that lead to UpToDate.

What ever, is there a way to query/GET (REST or Event APIs) a given or any Folder has the “Revert Local Changes” displayed in UI ? I found you already offer POST to revert, but I’d just need a GET.

… BTW, notice the text in the button (and this thread title and OP) covers both additions and changes, isn’t it ? Wouldn’t this drive to an easy/not-mind-conflicting/coherent decision about what to display as an overriding status for a collapsed Folder (just a thought)?

Thank you all devs for your great job.

PS: nothing related, but I’m champing at the bit for untrusted devices :wink:

1 Like

This change already happened, local additions is now displayed.


@cosas I’ve also came across the need to see when revert changes button has to be displayed and wondered why there is no GET endpoint. First a bit angry I then learned why it is not there and got lucky again: It would be too expensive to call the Syncthing REST API every time and for every single “UI element” one can think of frequently due to high cpu usage, expensive work to be done to gather the information from the DB(…). That’s why Syncthing has all info in the events (emitted via Rest Api) and “on-demand” in the /db/folder/stats call (see docs). It’s just not been obvious to a beginner like me which of the given info is relevant for the ui elements override and revert. To give you a hint, you can look at SyncthingController.js ( ) or . Hope that helps you a bit :-).

Thank you @imsodin, I never saw that before (reminder for me, search why I didn’t see that in Transifex… there’s a while since new strings didn’t appeared there…)

Thank you for the /db/folder/stats idea @Catfriend1. I looked the doc for this doc entry (because of its cool name :slight_smile: ) before I post here, but the comment:

Returns general statistics about folders. Currently contains the last scan time and the last synced file.

discouraged me to dig further here (note that I’m never angry against ST, only sometimes puzzeled, what I always credit to my lack of knowledge… and laziness to jump in the developers universe :sweat: ). At a first glance I though you drove me there (I’m not a native english reader) so I got a look, but unfortunately, the doc is …UpToDate :wink: You guess fine, my signature would be forEverNewb.

This is an expensive call, increasing CPU and RAM usage on the device. Use sparingly.

This comment in nearly all REST API doc entries is a mystery for me as I yet query /rest/db/need?folder=xxxxx-yyyyy with a */15 crontab without seeing bad perf (a raspberry Pi)(1).

Whatever, like you, thanks to your second hint (.../rest/events...) and good doc, I found my happiness with

curl -ks -X GET -H “X-API-Key: myAPIkey” “https://localhost:8384/rest/events?events=LocalChangeDetected&since=

I noticed the “Revert Local Changes” button requires to be pushed twice to disappear, first to create a conflict file, second to delete it. I didn’t check if the POST rest/db/revert is required twice too to get the button to disappear.

I also looked at your 2 links, but sorry too much complicated for me.

(1) Although I must admit the return delay for /rest/events is noticeably longer on the Pi than on my i7 laptop

Thanks again

1 Like

In the past I used something like this (bash) but this event type looks interesting. Is this a new type (didn’t followed the whole API development)?

if [[ "${ARGS}" = "-r" ]]; then
    if curl --silent -H "X-API-Key: ${AKEY}" "${HOST}/rest/db/status?folder=${FOLDER}" \
        | grep -q 'receiveOnlyChanged.*": [1-9]' ; then
        curl --silent -H "X-API-Key: ${AKEY}" -X POST "${HOST}/rest/db/revert?folder=${FOLDER}" && echo "Modifications reverted!"
        echo "No modifications."