ST keeps complaining that " peers who had this file went away, will try later". This is a false statement because no node lost its connection and those files has never changed. So it seems to me that there is a high level stupidity that ST plays in place.
After investigating the issue I found that, ST on the node that compalints about it, creates .tmp versions of those files consistently, then complaints that peers who had this file went away.
The issue persists even after I remove the temp files and restart ST on the node. Bear in mind that the other node that shares this share actually was send only originally. Even then the receiving node had this issue. So I do not know, this is definetely not a user error rather ST acting silly.
I am really not interested in deleting my index because this particular share is like 400gb and takes forever to rebuild that index.
Typically this means the files changed without their modification time changing. Common culprits are media files (something changes their metadata while preserving timestamps) and truecrypt (doesn’t update timestamps for security reasons). Windows shadow copies also do funky things here. We can’t say much more without knowing what sort of files they are.
Updating the timestamp on the sending side (so they are rehashed by syncthing) is usually the solution.
As a more personal sidenote - are you sure you want to be using Syncthing? You seem to be having a lot of issues with it, and not particularly enjoying the experience. You might want to look into the alternatives.
They are media files (mp3) but nothing is changing their data at all because this is almost like one way, meaning that only the sender ever changes them. The receving node is just a server that i do not interact with it.
Btw updating timestamps of those files on the sending side did not resolve the issue. Also there are no WIndows nodes like I said both are runing Linux with Btrfs
I have the same problem on my machines. The only way I have been able to resolve is to delete the .tmp files on the machine that indicates the sync failure, then manually copy the files from the source machine to the other machines. But then again, I am synchronizing 3.2 million files across 6 servers, so my situation may be little different.
That exact solution did not help me either. Believe me I tried that.
What is so interesting is that if I delete those folders from the sender, the receving side sends those files back to the sender! They just magically reappeared on my sending side. BAsically the receiving side did not understand that the files were deleted. Although at this point the sync is send and receieve on both. Initially this was sender only and send/receive setup.
The main issue I have with this problem is that it keeps my computer’s cpus very very busy. It keeps trying to resolve the issue every couple seconds which results in high cpu use by ST. Even this does not make sense why should it try it every couple seconds, would not it make sense it should give up trying it every couple seconds after some amount of triesa nd roll back to minutes then hours maybe so there is no unnecessary power consumption really. It is clear that ST is not able to resolve this by its own.
Well, that statement might be true in some cases but not in my case.
I deleted those files 5 times already with the .tmp files over and over again to force the receving side to give up being silly about those. And no media apps are using those files, noone is listening those files and I am the only user of those nodes.
Has this been resolved. I have deleted the folder sync on the peer with the error and then re-synced it but the problem persists. I have read nearly a dozen threads but there doesn’t seem to be a definitive answer as to what to do to fix the issue.
My configuration is simple.
(Windows server 2012) Network folder on server. Sync works correctly.
(Windows 10) Folder on laptop. syncthing peers who had this file went away…
Latest version installed.
Using Synctrayzor.
Any help would be greatly appreciated as I love Syncthing and don’t want to give up just yet.