After updating to version 0.14.6 I have an out of sync issue between a Windows PC sharing a folder as master with a Synology NAS, this folder is only shared between these two devices and is quite large (250+ GB). The NAS now reports “Peers who had this file went away” on several files, the PC reports to be Up to date on the folder. The files are still present on the PC. Other files are still being synced correctly. After the version update I have used the “Override changes” button on the PC while the NAS was still scanning, maybe that is related to this issue.
I do not want to touch/change the files because the time stamps/contents should be maintained. I tried a rescan of the folder on the PC, this appeared to complete very quickly so I guess it just checked the metadata and not the file contents. Both nodes have been restarted. I’ve tried enabling ignore permissions on the NAS.
Did you restart them at the same time (both were down at the same time) or in a row, so that they reconnected before the second one got restarted?
Being down at the same time while restarting could solve such problems you have.
The screenshots are included below. I’ve masked some of the details, I think that will not be a problem. The last file received is not one of the failed files. The NAS is used to create incremental backups of the synced files.
The NAS seems to try to sync the failed files periodically. The line with failed items disappears while syncing, it then reappears and the “Out of Sync” status returns.
I don’t know how to disable the delta indexes, but what I did was changing the configuration version from 16 to 15. It send over a lot more data so I think it did at least reset the delta indexes. I’ve also did the “rescan all” on the NAS (since the rescan button wasn’t shown for the folder in question).
The time stamps of the files should remain the same, so I do not want to touch the files. So I guess I’ll try to delete the index from the PC to see if that helps…
You probably need to drop the database to drop delta indexes, and let it rescan, but as I said, touching the files should fix the issue you are seeing.
I know you have suggested that before, but as I already said twice in this thread I do not wish to alter the time stamps of the files. Changing the time stamps might cause confusion later when we no longer know that the time stamps were changed and why. Also it is not the most practical solution to chase down out-of-sync files, especially if the number of files affected would be larger.
In my opinion this should be regarded as a bug in Syncthing. Maybe the node which detects the issue should ask the sender to recalculate the hash? Or nodes could perhaps verify the hash while sending them?
The link below describes dropping delta indexes by changing the configuration version, it seemed to work but did not solve my out-of-sync problem.
There is already a bunch of tickets relating to this, yet the fix is not as easy as you think. If your software deliberately adjusts timestamps back when changing content, there is no way for syncthing to know that the file has changed, so it’s not always our fault.
Asking to rehash the file can potentially DoS the provider if the file you are trying to download is constantly changing (log files…).
I found out that you can repair the “95%” issue (bug? workaround?) by enabling the option disableTempIndexes per folder.
But it is not working all the time :/.
I understand that (although in my case I guess something else went wrong), so I thought adding rehash requests or rehash during sending might be interesting alternatives.
Apparently file hashes are already checked when receiving files, so I guess in terms of cpu load it would not be a big issue to do it during sending as well? It could do the rehash only if the existing hash is older than a certain threshold?
Another alternative might be a force rehash button, since the rescan button seems to skip hashing based on file stamps.
Perhaps a DoS could be circumvented by throttling the rehash requests. For instance, only rehash after three failed attempts of sending an unchanged file. If the issue persists after a rehash then not allow another rehash within a certain time period. In general I think that sending a file will take longer than rehashing, so then it might not be viable for a DoS attack anyway.
Alternatively, it could show a button to rehash the files in question similar to the override changes button.
Lastly, (at least in my case) I trust devices that I share my files with. If one would DoS other nodes maliciously than we’d remove that node.
