Status of folder with pending Revert Local Changes

Ref. issue https://github.com/syncthing/syncthing/issues/5968

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.

1 Like

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…

3 Likes

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.

5 Likes