Irritating global/local status

Hey there,

I have a server (master-flag) and another client. And i am getting confused about something. Scenarion:

  1. Master and Client are in sync
  2. Client deletes/adds a file within the synced folder
  3. Master shows “Out of sync: 1 entry ~128 B” and gives option to overwrite that changes

Now the confusion: The Server shows the Client “Test” is still “up to date”, but also knows that he isn’t because of that 1 unsynced file. If the synced folder on one device is totally different (added/deleted files), then shouldn’t it show “out of sync” or at least “modified”?

Also: What does “global status” stand for? In my scenario i would have guessed that it’s the status of my master, but it seems to be the status of my client (“8 eintries” on screenshot). Didn’t want to open a bug-issue in github because i have a feeling i just didn’t understand this right.

Here a screenshot to illustrate:

Best wishes

Have you tried refreshing the page? Let me know if it looks different after that.

Each file has a version, and global state is basically the set of files which have the highest version that we are aware exist in the cluster (the up to date set), local state is the set of files you have on your machine.

Have restarted, refreshed and rescanned, it stays on “up to date” though files are not synced. I understand that there is difference between files being added/deleted by syncthing or the local user. But in both cases, as long as on one client has not the exact files as the master-server, the display should not be “up to date”.

What i now tried was to modify a textfile on my client. It now shows on master, as expected, that 2 files (instead of one) out of sync on the folder. One is missing on the client, one is modified. But still, on the master-gui the status of the client stays “up to date”.

More confusing: On the client-gui now the status of my server-device is “synchronising 100%” and keeps that, even after restarting syncthing on both sides (master/client).

100% probably means that the file is so small from the total folder size perspective that it’s less than a percent, hence shows 100%.

So the only issue I see with your screenshot is the fact that from the servers perspective the client is shown as up to date, where as in reality it has an additional file which is not supposed to be there, same for the file which has been modified.

I am pretty sure there already exists a bunch of issues which relate to percentage/status display problems which also cover this.

Just to make sure the 100%-issue isn’t related, i created another big file on client-side, so that now on clientside the status of my master is and stays “sync 50%”. But still, with rescanning and reloading pages, on serverside the client stays at “up to date”. Should i open an issue on git for this then?

You can, but I feel it will already be a dupe since we have a handful of status related display issues already open.

For example: https://github.com/syncthing/syncthing/issues/1202

hi! I’ve had the same problem.

  1. There probably are made some changes on the slave client
  2. If you hit the override button all made changes on the slavedevice will be overriden with the latest status on the masterclient That’s what @calmh told me :smile:
    imho, it’s not really a bug because of little changes (some bits?) made on the slavedevice or am I wrong? :flushed:

https://forum.syncthing.net/t/sync-conflicts-and-master-folder/2936

Hi :smile: Regarding (1): Do you mean, that there are coming changes on the code, so this problem might not not happen in future? Or did i get you wrong there? Regarding (2): I know, that pressing the override-button corrects this problem. But my point here was, that as long as folders are out of sync, their status shouldn’t be “up to date”, because in EVERY sync-application that’s the meaning of “The folder-content is completely identical on both/every device”, where “folder-content” means every file and every bit of them.

@AudriusButkevicius without putting pressure on you guys, your linked issue is dated “Jan”. Is there some way to get a timespan when this could be solved/implemented?

Yeah, whenever someone cares enough about it and fixes it. Feel free to contribute.

1 Like

can’t say - I’m not a developer just a friend of syncthing :relaxed: