Syncthing permanently shows my other computer as being out of date (It says “Synchronizing (95% 1,011 MiB)”) even though it is not. Both download and upload speed stay at zero permanently. In the “files not up to date” it shows a large number of files. I checked some of the files and they are, in fact, synchronized between the computers (I even confirmed that md5 checksums of a few of those files are identical on both computers).
I recently reinstalled the operating system, wiped the disks and restores the synced folder from backups. This may have caused the problem.
The syncthing version I’m using on both computers is: v1.0.0-ds1, Linux (64 bit).
I only now checked on the other computer and, interestingly, it’s saying that the other computer needs syncing. The list of items that it claims need to be synced contains some of the same files as the other computer and some different ones. I.e. the situation is “symmetrical”; both computers say they themselves are up to date and the other computer needs to be synced, but the syncing never progresses.
I upgraded Syncthing to 1.1.1 on both computers and restarted it, but unfortunately the problem persists.
Now that I check, it looks like all the files that refuse to sync are from the same (huge) folder. Here are a few sample filenames (the total number of files refusing to sync is 18,875):
Harjoituksia/Udacity: deep learning/ass1/notMNIST_large.tar.gz
Harjoituksia/Udacity: deep learning/ass1/notMNIST_small/A/MTAuMTUgU2F0dXJkYXkgTmlnaHQgQlJLLnR0Zg==.png
“Harjoituksia/Udacity: deep learning/” here is the common root folder for all the problematic files.
That’s unexpected. Can you share screenshots of the list of files which are out-of-sync. And query the REST Api for a simple file on both sides: https://docs.syncthing.net/rest/db-file-get.html
An update: I realized I had a filter on the other machine that prevented syncing most of the files. I vaguely remember setting up the filter some time ago exactly because the files were permanently out of sync. I removed the filter now and this reduced the number of permanently out-of-sync files to only 7.
That sounds nothing like the OPs experience. You mention a “receive only” folder, which acts differently. For example if you have any locally modified files, it is expected that you look out of sync from a remotes point of view (because you are).
Then you are talking about starting again - again a totally different topic. It is known that initial syncs of huge folders are a very heavy operations and can take a long time. There’s probably (well surely) room for improvement there, but it’s hard, and on top of that, there may be a specific problem that you encounter. However to help you with that, please give detailed information of what you did and what happened, with screenshots. And do that in your own thread please.
I had something similar happen to me with two devices both at version 1.1.1 (a third is also part of the share, running at 1.0.0-ds1, but is not on as consistently as these two servers). The only thing I did that may have had some hand in triggering it was that I had a share that had been created without large blocks, but that then had large blocks enabled on the devices. Then, I changed the file permissions for a large group of files on each server independently at roughly the same time (off by a few minutes). I did not change the contents, but these were all files that were hashed prior to enabling large blocks, and were large (>1 GB) files. Since then all those files refuse to synchronize, and permanently show as out of sync on each server, but both servers think it is the other that needs to be updated. Other files in these shares synchronize without issue. I’m currently trying to have one recreate its database to see if that helps.