How to accept local changes

Looking at my folders, actually I have now only two Local Additions folders for which I can press the button. The other folders in this state are for a device which is currently disconnected and I have no access to it, so pushing the red button could delete everything. And other folders are for the unidirectional backup of photos, which I will have to resolve in a different way.

So we have now only two shots. Don’t you want me to enable some logging before I press the red button?

Two shots is fine, just go ahead with the first as is :slight_smile:

After the first press of the red button, also the “Local State (Total)” and “RAM Utilization” have changed. After the second press, these two properties did not change. It looks like - as @Andy noted - that the first time the operation was performed, and the second time the GUI was updated.

1 Like

First of all if I could award you a medal for “Highly helpful and valuable debugging”, I would!
(i wanted to put “compliant” in there, but while maybe technically correct, it’s definitely not fitting :smiley: ).

my hypothesis is, this is just a refresh problem, i.e. refreshing the browser would have the same effect as pressing the button again.
Can you check that and then open an issue on GitHub with the latest screenshot and since description please.

Hard to say. I refreshed the GUI first, then I pressed the red button (once), and this sufficed to resolve the problem. So it’s evidently not that simple as non-refreshing GUI. However, last bullet was shot, for now.

Concerning the Android write problems to the SD Card, I’ve learned that this problem won’t be fixed in the near future if ever. That’s mainly because of the lack of support from the Go language team for Android, and because of technical difficulties for making a workaround. :frowning: :frowning: :frowning:

Hence I have to return from the bidirectional sync back to the unidirectional sync.

Hence I’d like to ask you on how to get rid of the out-of-sync device representing the phone. There are plenty of files waiting for synchronization, but it shall never happen.

make sure the files are the same on the nas as on the Android, either manually or by pressing override changes on Android - that will however delete anything that’s on nas but not on Android

I meant the device, not the folder. The device now has plenty of files waiting for the synchronization. I have no idea how to clear this list, as the target device does not accept incoming files.

I have also created a related defect for the Syncthing docs: https://github.com/syncthing/docs/issues/500

are these note the ignore delete items?

These are the files (photos) that were originally synced from the phone to NAS, and then removed from the phone. Now they are only on NAS. After changing the folder type from receive-only to send-receive (and resetting the index, probably), Syncthing wanted to synchronize them back to the phone. Now they are prepared to be sent, but the phone doesn’t accept them. Changing the folder type back to receive-only didn’t help as the files are already queued on the device.

Ok, so NAS ignore delete, phone send-only. You probably want to enforce the view of the phone on everyone: Hit override on the phone. The files will keep existing on the NAS, as it ignores deletes.

Thank you for your patience with me.

This helped - a bit. There are four parts in the sync chain:

Folder@phone → NAS device reprezentation @phone → phone device reprezentation @NAS → folder@NAS.

Before I pressed the override button at the phone, the folder@phone and the device@NAS were out of sync (showing the same set of out-of-sync files, cf Syncthing-device — ImgBB), the folder@NAS was synced (I haven’t checked the device@phone).

After pressing the override button, the folder@phone and device@NAS became up-to-date, which is good. But the device@phone and folder@NAS now have become out-of-sync with the exactly same set of files, but size 0B.

I know it sounds complicated, but basically the out-of-sync state only shifted to the right and changed sizes:

from: F/1GB -> d -> D/1GB -> f
to:   f -> D/0B -> d -> F/0B

the capital letters denoting the out-of-sync/size.

So now I am again in the situation Syncthing-Out-Of-Sync — ImgBB, with the exception that there are now hundreds of out-of-sync files. And also the device@phone is out-of-sync too. :frowning:

Edit: It seems that I have to wait till the fixes you made yesterday are propagated to the build for Synology NAS, in order to be able to correctly asses the current problems.

It was indeed more than just a refresh problem - thanks for discovering and providing info until it could be nailed down and thus fixed! lib/model: Unset local flag on deleted files (fixes #6436) by imsodin · Pull Request #6449 · syncthing/syncthing · GitHub

I don’t understand this, sorry. The usual way to depict setups is by giving every Syncthing device a name (I am now not sure whether it is one phone and one NAS, or multiple?) and every folder (by folder ID) a name and then state which devices share which folders and how. Made up example: Devices A, B and C, folders F1 and F2: F1 is shared between A (send-only), B and C (both send-receive) and F2 is shared between A (receive-only) and B (send-receive).

That’s probably a good idea anyway.

The usual way to depict setups is by giving every Syncthing device a name…

I meant (for the purpose of this example) that I have two (physical and Syncthing) devices (phone and NAS) that share a single Syncthing folder. But there is also a physical folder assigned to this Syncthing folder on each device. And (it looks like) there is a queue of the files to be sent or written for each device and for each physical folder - and this is what I was talking about.

But it is not important now, I’ll have to wait for the new version first.

1 Like

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