Yes, it is set to send-only, and due to the problem with privileges, I cannot change that. But I do NOT want to delete the files from NAS! That’s why I originally had the unidirectional sync set with ignore-delete. Now I changed it to bidirectional sync, but again with ignore-delete. I want the photos synced from the phone to remain at NAS until I move them manually out. I do not want the deletion at the phone side (e.g. because of the SD card becomes full) to result in removal of the photos from NAS.
Of course, I can backup the photos for now and perform experiments, but only for a limited time. After resolving the problems I want to return to the described state.
There’s no Override Changes button on either side (not at the NAS side, neither at the phone side).
There’s Revert Local Changes button at the NAS side for the folders in the state Local Additions. Pressing it didn’t result in anything, there are still the same Locally Changed Items as before. There’s nothing in the log about this action.
I am confused: Is that folder now receive-only and has ignore deletes set, and the files shown as locally changed are deleted on the other device? In that case it’s debatable whether those files should be out-of-sync or locally changed, but nevertheless the behaviour is as intended (the files aren’t deleted).
No, early in this thread @AudriusButkevicius suggested to change the folder from receive-only (which was its original setting) to send-receive, see my post from Mar 17, 11:21. Here all the problems began. Now it is still set as send-receive at NAS and send-only at Android (because of the problems with SD-card privileges). Ignore-delete is still set for the folder. The folder is now in the out-of-sync state, see https://ibb.co/dLDdSdR.
The other folders, that we were not discussing much, got into the Local Additions state, after reseting the index. see my post from Mar 18, 12:11, and https://ibb.co/kqrQjJW.
That’s kind of my problem, too many different folders floating around - thanks for the clarification
For the “Backups” folder if the files are actually deleted on the send-only phone but exist on the receive-only NAS, they are expected to be shown as local additions - that’s just what they are.
So as far as I understand there’s nothing wrong at the moment. If my understand is wrong, please explain.
When you set ignore deletes it ignores deletes, it is out of sync/has local additions. You can either have it delete those to get in sync or retain them and be out of sync - those are mutually exclusive.
That I can’t connect to earlier posts, please explain.
That I can’t connect to earlier posts, please explain.
See my post from Mar 18, 16:04.
When you set ignore deletes it ignores deletes, it is out of sync/has local additions. You can either have it delete those to get in sync or retain them and be out of sync - those are mutually exclusive.
I’m not sure I understand what you mean. I expect that when I set ignore-delete, the deletions will be ignored, and not shown as local changes.
But we are discussing several different problems together. The out-of-sync is one problem, the locally-changed-items another one.
Out-of-sync: the NAS folders are set as send-receive and ignore-delete. Because of the corrupted out-of-sync items list, I cannot tell what files cause the problem.
Locally-changed-items: the NAS folders are set as receive only; some are set as ignore-delete, for others the deletes are allowed.
In the former case (i.e. with ignore-delete), the synchronization behaves like unidirectional backup from phone to NAS (new files are added, none are deleted at NAS side). Here the local-changes are caused by files that are present at NAS side but have been removed in the phone. However, Syncthing reports total size of these local-changes 0B, which is not true.
In the latter case (i.e. with allowed deletions), the synchronization is in effect the unidirectional mirror from phone to NAS. Some of the locally-changed items look like syncthing/config.sync-conflict-20200225-121928-2A33OWZ.xml or anything.sync-conflict-..., they are present on neither side, but probably were present somewhere in the past. I guess they are remnants of Syncthing artifacts? The other locally-changed items exist at the NAS side (I do not have access to the remote device, so I cannot say the state there). However, in all cases, Syncthing again reports total size 0B.
Indeed looks like a (cosmetic) bug. Please post an issue with one of the screenshots that shows the problem to github.
IssueB:
That’s definitely wrong, but it’s unfortunately not clear what might be happening there, thus can’t be fixed yet. Thus it requires further debugging, i.e. enabling model debug logging (actions>logs) and then pause and unpause the folder. Then make the logs from that period available please.
That’s not how it works. That’s why it’s an advanced setting, it is just a workaround with the drawback you see. Not saying it couldn’t be better from a UX perspective, but it just is how it is (aka if anyone wants to do this properly, maybe it’s doable - not on the roadmap for me).
If you push the red button twice, is both away, the 0B and the button.
I think the visualization and presentation of the processes and the status should be worked on. There should be distinctions in it.
For me it makes a difference whether an “Out of Sync” with a %-indication is given in a bidirectional or unidirectional synchronization. What is a disruptive factor in bidirectional synchronization, which usually hides an error, this state can be okay in unidirectional.
But then the “Out of Sync” should be called “Valid Differences” and the synchronization should show “Current”. However, if there is still an “Out of Sync” with a %-value, it confuses the viewer and thinks something is wrong.
Red buttons are red for a reason, don’t tell people to “press them twice” without specifying clearly which red button you mean and why they should do it.
Do not hijack other threads.
Literally the two posts above yours acknowledge there’s various problems here, i.e. it is hard to keep track of what is related to which problem. Bringing up at best loosely related issues is not helpful. If you believe you have something helpful to bring up, open your own thread.
I’m just talking about an effect that I’ve found. If I re-create the problem and reset an inequality with the red button, the directory contents are the same again, but I also see in the GUI a number of unsynchronized files with 0 bytes. If I click twice on this red button, this display is also reset and the number of unsynchronized files with 0 bytes also disappears.
@Andy Yes, perfect, I can confirm that it works! However, I haven’t checked what it did with the content of the folder.
@imsodin I tested that on a single folder, so the other folders are still available for your investigation, if you are interested. I’ll post the info you requested later this day.
Issue A and B are clear now, fix is incoming. If you don’t mind please create an issue with the screenshots and mentioning ignoreDeletes at https://github.com/syncthing/syncthing/issues.
You also need to specify the folder ID and path, something like curl -H "X-API-Key: XXXXXXX" 'http://192.168.28.2:8384/rest/db/file?folder=ID&file=path/to/file'. Also note that I quoted the url in single quotes due to the special characters.