I am experiencing the same issue as the user at this link, but I am on Windows 7 x64:
The issue began when I reset my Android to factory and reinstalled Syncthing. What I like to do is sync all my files to a landing folder on my PC and then move those files to their proper folders elsewhere on my drive. The problem is that the files end up getting resynced back into the landing folder. It didn’t used to do this. Somehow, Syncthing used to be able to know what it had previously synced so that it would ignore it next time around.
I have my folders on Android set to Send Only. Also, something new I just noticed is this “Override Changes” button on the Android app. I never saw this button before the reinstall and it seems to be what triggers the resync to occur.
I just want to get it working the way it used to, so here is what I would like:
I run Syncthing and it syncs files from Android to landing folder on PC
I remove files from landing folder
Syncthing will not attempt to resync those files
Syncthing will also not attempt to sync/propagate deletions that occurred on my PC to my Android
Your post is not clear as to files getting resynced back to the landing folder on what device? It cannot get resynced to android as it’s send only, and PC cannot re-fetch it from android if you deleted it from android.
You should be more specific what you are doing on which device and what are you seeing on each of the devices.
I am using Syncthing with Windows 7 x64 and Android
After I sync from my Android folder to my PC’s landing folder and then move the files from my landing folder to another location my drive (or outright delete them), running Syncthing again will recopy those files from my Android back to the landing folder
As I mentioned, this used to not be the behavior prior to reinstalling Syncthing on my Android after the reset. Before, it was a one-time sync from Android to PC. Syncthing would keep track of all files that were previously synced so that it would not attempt to sync them again even if they were removed from the destination folder (which is on my PC).
And I will also reiterate how the Android app is now showing an “Override Changes” button beneath each folder definition. I’ve never seen this button prior to reinstalling the Android app.
This would imply something changed the files on android, which caused them to promote a new version which then got synced back to the PC. Did you check that file size and modification timestamps are identical on both copies? I suspect they will not be.
I compared file dates, times, and sizes on my phone with the files on my computer and they’re identical. Here is what happens:
I sync files from my Android to my PC
I move/delete the files from PC
Syncthing on Android then displays the OVERRIDE CHANGES button as shown below. Prior to reinstalling Syncthing on Android, I never saw this button before. When I tap it, it triggers the event that causes all the files I deleted from my PC to be recopied.
So one could argue that all I need to do is not tap that override button. However, I am not keen on this as a solution because it’s very easy to accidentally tap the wrong place on your screen, and an inadvertent tap in this case results in potentially hundreds of megabytes of images and videos to be recopied to my PC. Plus, it’s sort of an eyesore because it makes you think something needs to be overridden.
So what, exactly, is this OVERRIDE CHANGES button and why am I suddenly seeing it only now?
And now something else just surfaced that I’ve never seen before. In the web app that runs on my desktop, I now see a Revert Local Changes button as shown below. I clicked it to see what would happen and it disappeared without any indication that anything happened at all. I am really confused as to why Syncthing is exhibiting behaviors that it never did before.
So I’ve done some looking around and it turns out that this button has been a source of grief for Syncthing support. I somewhat understand what it does now, but, as I’ve mentioned a few times, this override changes button is new to me and I’ve been using Syncthing for close to a year now. In the past, I was able to:
Set up a sync folder on my Android as send only (I believe this constitutes as a “master folder”)
Run Syncthing to copy that folder’s files from my Android to my Windows machine
Move/delete files from my Windows sync folder without the Android app reporting that I need revert the changes made on my Windows machine to bring the two folders back in sync
Therefore, I’ve concluded that the way I configured the folder this time around differs than the way I had it configured on my Android before I reset it to factory. So, now that I understand more about Syncthing, I can pose my question more succinctly so that there is no confusion:
How can I configure my Android folder so that:
It’s send only (ie, master)
It only cares whether or not the master files have changed
It doesn’t care whether or not any files on any of the receiving nodes have been changed or deleted
This only would have happened if you had ignore deletes enabled (advanced option via web ui on android), even then, moves are creates + deletes, so you’d have override changes undoing the creates.
You can’t setup syncthing in a way that does not care if another side has changed files, syncthing is bidirectional, and what you want to do is unidirectional which syncthing doesn’t do. I have no idea how you set it up previously, but
Even if other side is setup as receive only, you’ll still have conflicts when you two sides change the same file, prompting buttons to appear.
So this worked and must have been what I did before. In a way, it mimics unidirectionality with regard to deletes only. I’ll also add that, in order for this to work, you cannot modify any other files that remain in the child/receiving folder. If you do, this constitutes as being out of sync and the deleted files return (which doesn’t make sense if I have it set to ignore deletes). Also, the files I modified in the child folder do no get reverted by their master version. At any rate, I will only worry about those issues if they present an issue in the future. For now, I am going to consider this issue closed unless it turns out that the issue continues. Thanks for you time and providing the winning solution there.
