.stignore causes encrypted (untrusted) nodes out of sync

I have two trusted nodes T0 and T1 I have one untrusted node U2

T0 and U2 does not talk to each other (on purpose) T0 ----> T1 ----> U2

T0 sends two folders (in one share) T1 has .stignore configured so it does only receive one of these folders U2 receives encrypted data from T1 and does not have .stignore

T1 then reports that U2 is in “Syncing 50%” state, which obviously will never get fully synced because T1 blocks half of data to it.

In fact that is exactly what i want to do, but i cannot easily tell if the non-ignored files are synced, because this always reports sync to be stuck.

Perhaps if i move the .stignore from T1 to T0 it will be better? It now seems obvious when i think about it :slight_smile:

Update: it actualy helped :slight_smile: if i don’t want to sync something in syncthing mesh with more thant two nodes, i obviously need to ignore it on the device where the ignored data is originating from.

Yeah there’s some corner case here. In effect T1 (when it has ignore patterns) processes incoming (ignored) updates from T0 and marks them as intentionally ignored, so it knows it’s up to date. But it doesn’t know that U0 (or any other normal device, I don’t think encryption matters in this scenario) isn’t in contact with T0 and will expect it to report the “whole” folder…

In fact it does know that U2 doesn’t have direct contact with T0. Theoretically at least, because they each send their other peers in the ClusterConfig message. This just doesn’t get factored into the expected state, and it’s far from a trivial problem to do so.

Note there could be a common fourth or fifth device T3 / T4 that closes the circle between U2 and T0, which T1 will never be able to know. But regarding what state T1 expects on U2 and what completion is shown, such topologies can be ignored IMHO.

In general, what would happen if the device completion percentage always used the subset of locally not ignored files as reference, not the global state? We cannot be sure what maximum state can be reached on the remote (see above), but we can report how much of the data it has in relation to everything the local device will ever be able to supply to it. This “uploaded / available” ratio would be honest and accurate at least.