Well not entirely, but in a lot of cases:
So many users are confused by Syncthing telling them that it is syncing, while they know that the data is the same on both devices. And they are likely right, Syncthing is not “syncing”, it’s just crunching on internal metadata - that’s an implementational detail. That may be a bit overstated, as that detail may use lots of resources, but it’s definitely not doing what you would intuitively expect when reading “Syncing”.
My proposal is to rename the state on devices to “Out of sync”. That’s an already established term and is always correct, regardless of whether the device is syncing or not. A possible enhancement would be to change that state when there are ongoing request from a device, but that’s a more extensive change.
And for folders I see two options: Either use the existing “out of sync” state while we are crunching metadata, but are not yet actually syncing any files. Or add another state for the “crunching metadata”. I am in favor of the latter, as there can be a significant difference in resource usage between sitting idle being out of sync, and crunching metadata. It should also be easy to implement. The hard part is getting a concise, understandable label for “crunching metadata”. Maybe “Comparing items” or “Comparing state” or “Preparing sync” (actually I kind of like the last one)
I also had the same idea when I was waiting for sync of a large file to start (see my comment here).
“Crunching metadata” sounds cool, but does not fit (also not easy to translate). For me the “preparing sync” is better - but whatever the wording will be: most important is that there is a (visible) progress, e.g. counting the meta blocks infos that are transferred as percentage of total meta block information or something like that. Maybe an ETA display would also help.
That was never meant as a real proposition for the UI - that’s just my supposedly funny working title
Now here I believe you are thinking about Add progress indication to folder metadata check · Issue #6016 · syncthing/syncthing · GitHub. What I am talking about here is not the exchange of metadata. It’s the phase of pulling where we go through the database to see what we need to sync, then compare what we need to sync with what we have and update items which do not need to actually sync data. Only after that we actually do sync data (if at all). To give a progress indication we’d have to iterate twice over the db. Or there could be just an indication of how many items have already been processed. That would at least be an increasing number.
“Preparing sync” sounds like the next step which will happen will be the actual synchronization (unless the preparation failed). It sounds like the need to synchronize had already been decided. Why else preparing it other than consciously wasting resources?
But as I understand it, in this phase it is actually still gathering information to decide whether synchronization is really necessary. So “Considering synchronization” would make more sense - especially because the initial reasoning for the change is to avoid that kind of confusion.
Note that I’m not a native speaker so I could be wrong with my comprehension of the word preparing. There might also me a better alternative to considering. I also like the other alternatives given in the initial post.
All propositions aren’t factually entirely correct, and I don’t think it’s required to. In this phase it does tons of different things. What I’d like to convey is “doing stuff to get in sync, but not actually transferring anything”. I think “Preparing to sync” quite close. And can’t you prepare for something and when finished, realize there’s nothing left to do?
I like “Preparing to sync”. Once it has finished preparing it might go to “Up to date” immediately if it turns out the folders are already in sync. That seems to me like an acceptable situation as now the files are in sync. Who cares if it’s not apparently doing something that it was “preparing for”? Unless it’s fundamentally broken somehow, the files are now in sync. Great! The user should not need to be concerned at this point if they can trust that the files are indeed now up to date.
Incidentally, I’m pretty sure Dropbox/Google Drive do the same thing with their software at startup. They check the current state of files and then sometimes immediately move to an “everything’s good” state.
That will still be the case though. The “preparing” part is figuring out that the 64 GB file needs syncing or not. If it does, we start “syncing” and then copy or download blocks as required. If most of it is unchanged there will be very little network activity for a long while.
Also, don’t forget that we might handle more than a single file at a time, when do you prepare when do you download? Reports of “one of the files is stuck” while we hash the temp file coming in 3, 2, 1?
I didn’t interpret this as being at the file level. Rather that when we’ve received index updates, and we’re walking the need table and queueing changes, we are “preparing”. Once we’ve done that and start a puller iteration we are “syncing” as usual. All the file IO happens in “syncing”. If there were no changes to handle then we never went into “syncing”, just “preparing” and then back to “idle”.
If we think it’s conceptually problematic to prepare for an action and then not take the action, then “considering changes”, “contemplating sync state”, “meditating” or something like that could be a different wording. It should be fine to at least think about something before acting.
Do you think it is possible to have any kind of progress indication? e.g. 10 of 100 blocks/database entries checked = display “Preparing (10%)”
My wish is to avoid a new state that stays there for a long(er) time without (again) showing that Syncthing is doing black magic important stuff under the hood