Folders show up to date but still syncing?

[netbox]

Hi everyone,

I have had a little problem show up with syncthing over the past week or so. I’m not entirely sure, but it might have been since the last automatic update, which I believe was fairly recent too.

I have system A syncing to system B. On both systems it is showing on the left hand side of the UI that all folders are up to date. But on system A on the right hand side, it is reporting that system B is “syncing 99%” with about 6GB left to sync, although there is no upload or download activity taking place. It was showing 9GB at some point but is now stuck on 6.

I just wanted to know what this could be. When I click on the right hand side of System A to see which files it is reporting as not being sync’d on system B, it shows a whole list of files that do actually already exist on system B - and in some cases, files that have been deleted on both systems, and to be sure, I deleted out any *.tmp files on both sides in case that was causing it.

Based on my limited technical knowledge, I’m thinking that the database might be slightly corrupted? I probably don’t help things by sometimes manually adding files to system B and then not reverting local changes - for example, if I download a large file like a Windows 10 ISO file to System A, I might sometimes remotely login to system B and download the same file to save syncthing having to deal with it.

I’m hoping the database isn’t corrupted and that it is a simpler issue. To confuse me even more, even though both sides are reporting up-to-date on the left side of the UI, system B is reporting a local state difference of 1 file to system A, and this shouldn’t be happening where the folder on A is set to send only and on B to receive only. But it is happening, and I only noticed because I manually checked - system A didn’t report (and hasn’t reported) that the corresponding folder on B was out of sync.

For extra info, both systems are running the latest version of Synctrazor and syncthing on Windows 10. System A is set to send only, B to receive only. As I said above though I do sometimes manually add large files to B and wait for the database to update itself, and this has seemed to work in the past. I do this because my internet is terribly slow on one side not to mention that I am still struggling to configure things properly so that I don’t have to go through relays.

Hope someone might be able to offer an explanation in any case. Thank you for your time and help.

[AudriusButkevicius]

Picture speaks a thousand words, so please provide screenshots, from both sides.

[netbox]

I will provide screenshots when next remotely logged in to System B, but in the meantime, I am spending more time to scan existing support requests, and my problem is very like the following: Out of Sync Items issues

You answered the query yourself Audrius, and it seems that in this case the best that the user could do was to add a new folder, move the contents and allow it all to re-sync/re-index which takes a long time. The difference between me and this user is that I don’t have any ignores in place - my “out of sync” items that are being reported on System A directly correspond to the files that were changed locally on System B, i.e. not synchronized from A to B. But what normally happens is that Syncthing on System B recognizes that they are the same files and everything gets reported as up to date…

Is there not a way to get the index files to refresh, or to verify themselves between the two computers?

[AudriusButkevicius]

I suspect it’s either mismatch between shared folders or some failed items on either end.

[netbox]

The global and local states match on the master machine.

On the slave machine, the global state is reported as 1 file more (literally 1 file) than the master global state, and the local state is reported as 1 more file still (a total of 2 more files to the master global state)

There isn’t a mismatch between shared folders otherwise.

However you are right that the slave machine was reporting “Failed items” a few days ago. This has now rectified though, and on the left-side of the UI on both machines, it says up to date.

My best theory right now came to me a few minutes ago after having read through all of this thread HELP: Syncthing is redownloading already existing files! - although the topic was about re-downloading existing files (which has happened to me before and I could only solve it by deleting the file altogether) the topic was fascinating to follow and I see that you eventually found a solution in telling the user to delete the metadata blocks and let it rebuild. What was also very interesting though is that the corruption came about because of the “variable sized blocks” feature. In my case, I have been ticking that box at different times recently for different folders on each machine, so I am now suspecting that doing so has lead to Machine A reporting the Machine B state incorrectly, because of the way things have been hashed.

I am thinking of turning off the variable blocks on the shared folder on both sides, and letting it re-scan/re-hash - do you think this would be worth trying? Might be faster than deleting the index altogether. This is my best idea right now other than deleting the index, which would affect all the other shared folders!

I also concur with the user on the other thread - despite these issues sometimes, Syncthing is a brilliant piece of software and I’m very grateful for it. Thanks for all the amazing work to all the team.

(One aside question - as a rule, with a mixed folder of many small files but also many large ones, i.e. thousands of photos with dozens of large ISO files, is it better to have variable size blocks turned on?)

[imsodin (Simon)]

Variable block sizes has no downsides on its own. Having a mix of on and off is bad and there may be issue when changing the setting on an existing folder with a newly added folder on another side. In any case it seems highly unlikely to be related based on your reports.

For the weird local/global states it would definitely be a good step to recalculate them. If the problem persists we have an angle for debugging, if not one aspect is ruled out.

The first thread is unlikely to be related, since that version a bug (or more) has been fixed that can produce the described symptoms.

[netbox]

I note what you’re saying about the variable block sizes, so I won’t change anything. The shared folder I’m having problems with has variable block size ticked on both machines.

I don’t know why the global/local states were different, or how to recalculate them as you suggest, but I did find that Syncthing was re-creating empty folders on the remote/slave machine that had been deleted on the source machine. I think that with the speed I sometimes create/delete/move files, perhaps Syncthing struggles to keep up with the changes. I manually found the different folders and deleted them on the remote machine, and Syncthing now reports the same as the master machine.

With regards to the master machine on the right-hand side of the UI reporting sync activity, when the remote machine shows “up to date” on the left-side of its UI I think it might have something to do with the modified times and dates of folders and files. I ran a robocopy command to mirror only the time attribute of folders and files in the syncthing shared folder (using parameters /e /mir /copy:t and /dcopy:t) and sure enough, the times were changed on the remote machine without affecting files. Syncthing is now as I write still reporting a sync action on the master machine, but the amount is going down slowly, from 6GB where it was stuck before, to 1.49GB right now.

I decided to try this approach rather than delete the database. I don’t know yet if it will work, but if you know in any way that different times and dates of files on a remote machine can affect a sync, it would be great to learn more.

Also do let me know at which point it is good to have variable size blocks turned on in a shared folder…

Thank you!

[netbox]

Just to give you another update.

My method of robocopying timestamps seems to have cleared things up with ONE exception.

On Machine A, on the right hand side, it is now showing 6029 items out of sync, with a total size of 0B and the folder is only 95% synchronized. So this has become the issue.

I’ve searched the forum and a few people over the past year or so have had the same issue. They were advised to run the following Powershell command:

(Invoke-WebRequest -Method Get -Headers @{“X-API-Key”=“API KEY”} -Uri “http://localhost:8384/rest/db/completion?device=device_id&folder=folder_id”).Content | ConvertFrom-Json

I did that on the remote machine (where everything is up to date) and the result was:

completion : 0 globalBytes : 1956060138531 needBytes : 1956060138531 needDeletes : 0 needItems : 397498

This pattern has been replicated on two other shared folders, and from what I can understand, all of this should say 0.

I cannot provide the results from the master machine, (where everything is of course up to date, but the UI reports the remote machine as being out of sync) because the results of the powershell come up as:

“Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. At line:1 char:2”

I’ve noted from the other discussions that there is lot of talk about resetting deltas. But I have no idea how to do it. Could you provide instructions? Would this be time-consuming? Does it mean to reset the index completely and rebuild? Or is it a relatively quick command?

It was also mentioned more than once that this is “typical of a send-only folder” - now in my case, Machine A is reporting Machine B as out of sync, and although all folders are up to date on both sides, there are send only-receive only folders. I’d be interested to know more about the relevance.

Apart from resetting the database (I guess by deleting the index folder contents?) the only other idea I have is to open up the shared folders as 2-way folders, and perhaps this would give Syncthing what it needs to verify that everything is in fact up to date.

Look forward to your ideas and suggestions Thanks!

[AudriusButkevicius]

As I said, screenshots speak a thousand words.

[imsodin (Simon)]

Most importantly what Audrius said: Screenshots please!

Resetting deltas just means starting Syncthing once with the -reset-deltas command line option. This also happens on every upgrade, so it’s unlikely to help (it’s relatively cheap).

Recalculating local/global states is done by setting the environment variable STRECHECKDBEVERY to 0 once when starting Syncthing.

There may be options for both in Synctrayzor, otherwise using the command line option should be straight forward and setting an env variable googleable (I simply don’t know about windows command lines).

[netbox]

I apologize that I haven’t uploaded screenshots yet. When I last got into the remote machine I had to carry out some urgent work and moved a lot of files around - I will wait for the sync to get back to “0B 95%” then will upload a screenshot of that, as this appears to be my only problem now. But others on the forums have had the same problem and have uploaded screenshots, so I’m not sure how useful they’re going to be to you…?

For the record I adjusted the timestamps on Machine B to match the modified timestamps on Machine A and that’s how I got my sync down to 0B from the previously stuck-at 6GB (although all files were up to date on both sides, with global and local states also the same)

I note what you say about reset-deltas and await the next release in June - perhaps this might automatically solve the problem. I also have a feeling that just rebuilding the entire index will too, but I wanted to avoid the time that takes. In practice, the error isn’t affecting my use of syncthing at all; it’s more about learning about Syncthing more as I integrate it into my digital life and use cases.

Thanks for your time in exploring this issue and I remain open to any suggestions. I hope that as more users report the same issue it might become apparent what causes it, although I suspect that in my case it’s creating/deleting/moving so many files sometimes that syncthing can’t keep up, and the indexes somehow get out of sync in a big way.

[AudriusButkevicius]

Sorry, but I think this is just a waste of our time.

I really don’t want to compute what the current state could be using a verbal description of syncthing’s state, and then have to mentally apply some random actions that you decided to perform as self remedy on top of that, and have to guess what the problem could be.

If you want to go the self remedy way, knock your self out.

If you want us to try to help you with this, provide screenshots and stop doing random self-remedy things in hopes it might fix things.

You might believe screenshots are of low value, but if we are asking you to provide them, it means they are high value to us.

If I tried to mentally compute syncthings state for every users description of that they they think is important, that would miss half the stuff that is important and my head would simply explode on the 3rd user report.

[netbox]

Of course. I understand what you’re saying. I’ll get some screenshots and post back, but if the problem sorts itself out beforehand, then I’ll leave it there and the thread will close. Thanks for your time again, and I’ll make sure to post screenshots in future at the same time I open the topic.