The difference standing out here is in fact permissions - 0700 vs. 0775. That should now be ignored after you enabled the option on both sides. But the entry on ISESWES is also “invalid: true”, which is probably normal for a receive-only folder. So I guess that the difference was recorded during initial scanning and now cannot be resolved because it is receive-only.
The good news is that modification time and blocks (content) looks identical, so there is probably nothing valuable to lose by pressing the revert button.
I’d like to have someone else, e.g. @imsodin take a look at the data, whether my interpretation is correct. You should also check the same differences for some of the other files, if there are any with actual content changes that might get lost (overwritten by the state of JIXTTVB).
Yep, all correct about invalid being normal and ignore permissions only mattering when there’s an actual change when scanning (size or mod. time change).
My understanding is that you never expect anything to change on the receive-only side. That’s why I am saying it should be fine to revert, as it will only reset the receive-only side, it wont affect the send only side. I obviously can’t guarantee that “everything will be fine”.
As I understand it, the OP’s concern is that Syncthing might end up trying to pull a significant part of the 3 TB data again in response to the revert action. That is however very unlikely if all files show the same pattern in only metadata (permission) difference. Because all data is already there and recognized, as the identical block hashes tell us.
I will try the revert button then - no need to check other files. When Syncthing did not do something with them, they sure are in the same state!
I re-read that I need to do this on the remote site, which I can only ask for.
I am still wondering a bit how this will be possible to fix the “syncing” issue on the local device - as it does not get information from remote, when I correctly understood.
But I dare not to remove the “push only” as never ever, changes at the remote site shall affect the local device!
That is of immense importance.
Going to ask the remote site to search for such a button and click on it!
Note that a receive-only folder does in fact provide information about its contents to other remotes. It is just marked as invalid, so others don’t consider it as affecting the global state. But they can of course determine whether the sent information matches the rest of the global state, and thus show whether the receive-only node is in sync or not.
I hope that explanation is factually correct. At least conceptually I’m sure that’s what happens. “Receive only” should not be taken literally, of course these folders do share their index data with other linked nodes. But they will never announce local changes in a way that other nodes will pick them up as affecting the global state.
