(Repost) Receive Only folder redownloading locally deleted files

Original Post

Making a new thread for this because the issue has returned.

I use Syncthing as a one way transfer between computer A (Send Only) and B (Receive Only). Files originating on computer A are sent to B then moved to their final resting place outside of the Syncthing folder.

Before when I would do this moved files wouldn’t redownload from A. Now on my new install of Syncthing (v1.27.3, Docker) whenever I move a file out of the Receive Only folder it immediately redownloads.

The issue fixed itself for a brief moment but then came back once I started using Syncthing more heavily. I deleted the Docker version and installed Linux 64bit v1.27.3 from the Syncthing website. The issue is still there, ruling out a possible Docker config problem.

I installed Windows 64 bit v1.27.3 and it doesn’t have the issue, so it must be something with the Linux install.

Isn’t this “by design”? When you set a folder (Computer A in your case) as Send Only it says:

“Files are protected from changes made on other devices, but changes made on this device will be sent to the rest of the cluster.”

I checked another folder which is set to receive only (Computer B in your case) and there it says:

“Files are synchronized from the cluster, but any changes made locally will not be sent to other devices.”

Deleting a file is modifying it in the worst sense, imho. So these settings (what is in between the quotes) is implying the behavior you see: syncthing is trying to keep things synced, it will download all the missing files. Side B has no saying over the contents of the folder. What you are trying to achieve can probably be done some other way, but not the way you set it up. Do you want the files to stay available at side A? One way i can think of: change side A and B to send and receive. But before that look into the file versioning mechanisms at side A: https://docs.syncthing.net/v1.27.3/users/versioning maybe Trash can versioning with a custom trash can folder would do it for you? Anyway i do not see a route possible where the files would stay available in the exact same spot on A while you need to be able to delete them on B without having them deleted on A. Or maybe that is what you need? Anyway what i can imagine is that you want some kind of transfer from A to B, the versioning can help you keep them on A, delete them after a while, move them to a different folder, etc. Im sure there is a solution for what you need.

Coincidentally i just checked (what i thought is desirable) what would happen if i delete one of the photos (on a network share) i have synced from my phone to my server, and as expected and desired, the file re-appeared.

No, the folder should state that is has “Local Additions” in the GUI, but reverting them should only happen if the user deliberately presses the “Revert Local Additions” button (or uses the API to do it, etc.). There is no mode in Syncthing that automatically reverts local changes, so if something like that happens (as the problem described in this topic), it’s a bug, not the intended behaviour.

1 Like

Ok, i keep reading over this again and this doesn’t make any sense to me. Please confirm:

Side A is set to Send only, Side B to Receive only.

Files are initially copied/moved/created at side A from outside folder A into folder A.

Then side B receives a copy of that folder.

Side B moves the files out of that folder.

Then the copy re-appears on side B.

Is this a correct summary of the scenario?

Before i put more effort into this, i need someone confirm. Why? Because i feel i am missing the point here.

And on the subject of clarifying; please explain what “the folder should state that is has “Local Additions” in the GUI” means in that context. On side A or B? What local additions are you referring to?

All is correct except the last point. Normally, there shouldn’t be any automatic “re-appearing” of the deleted files.

Everything said is about the Receive Only side only. The other side doesn’t really matter here. If you delete files in a Receive Only folder, those deletions will be marked as “Local Additions”. The GUI will also display a “Revert Local Additions” red button. If you press it, Syncthing will re-download the deleted files. This process always requires a manual user intervention.

In short, deleted files = local additions.

But they do, and that is not what you want, but i didn’t say there if they should or not, so there is no need to emphasize that, the qoute i made is still correct, so all is correct in terms of the scenario i described in the quotes.

Ah…i did see that once, but i only saw that happen when i modified a file in a folder that is set to receive only, not delete the file. Anyway it’s all clear now and i ran some tests; first i setup a test folder, creating the scenario we described. Then i went ahead and deleted some files at the receiving (only) end and you are right. The receiving end’s gui shows “local additions” and the ability to revert to the full sync, no automatic re-appearances of the files i deleted.

So i thought maybe there was something different on the receive only folder i mentioned i coincidentally did that test on, i checked but nothing apart from file versioning was different. So i took a photo with my mobile, waited for it to appear on the receive only folder on the server, removed the photo and guess what? No automagically re-appearance, just the “revert local changes” button!

I can only conclude i did something different when i tested it before or i was running a different version on at least one of the ends back then. I suspect its the latter. So right now with version 1.27.4 it seems to work as you remember it, as you desire and expect (i didn’t obviously). That version is out since march 5th, the moment i wrote my initial response i was probably just moments away from updating it.

Might it have been a bug that indeed came back in between versions? You were running the same version i see, the receiving end in my initial test is Linux too. Can you confirm the behavior is now good with version 1.27.4?

If so, than it is weird there is no mention of such a bug in the bugfixes with the current version…interesting.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.