Reverting folder 0x9b4180
Revert: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally
Now, this what I have found out and also what I am suspecting.
Changing the folder type to SR and then back to RO fixes the problem. Why it does so, I have no idea.
Clearing ignore patterns on the receiving side does not help.
I have the following ignore patterns in the folder on the sending side, which I think may cause this behaviour.
!folder/file1
!folder/file2
folder
The folder matches the actual folders listed in the “Local Additions”. However, I would still need to reproduce this behaviour in a clean installation to have hard proof though. Still, if this is really the culprit, then why would changing the folder type back and forth make any difference? Perhaps because files inside folder on the sending side have changed while the folder is being downloaded? Just throwing out some ideas…
A receive only folder only receives data from somewhere else. A newly created folder is by definition empty. Any files subsequently discovered are files that shouldn’t be there.
Or, more practically, never create an RO folder with pre existing data. Create it as SR and then maybe switch the mode.
The thing is that in this case the RO folders are indeed created empty (but with full .stignore, which is same as on the sending side), and still end in this state. The workaround is to set them to SR, and then change to RO again. After doing so, there are no Local Additions anymore. I am curious why this is happening though.
Yeah, and I have failed to reproduce the behaviour in my test installation so far.
Create a folder on Device A with the following structure.
folder
file1
file2
Create ignore patterns as follows.
!folder/file1
folder
Share the folder with Device B.
Accept the folder on Device B as RO with the same ignore patterns as above.
Unfortunately (?), in the test installation the folder does get synced properly with no “Local Additions”, which is not the case with my real folders.
As I wrote above, I have a feeling that the culprit are new changes inside the ignored folder that take place while the synchronisation is going on, which then manifest themselves in “Local Additions”, especially since the listed additions themselves are only the ignored folders, and no actual files.
Sounds like a possibility. I would also be unsurprised if the ignored-folder-with-unignored-children pattern didn’t cooperate wonderfully with receive only folders, since it kind of depends on the receiving side creating and managing the otherwise ignored middle level folder itself. Which it’s forbidden from doing by way of being receive only and such.
(Actual footage of Syncthing code resolving the conflict.)
I understand . I still need the patterns though, as tons of other files get created in those folders, but I need to sync only a few of them. Fortunately, once the first Local Additions get solved by switching the folder type to SR and back to RO, the future synchronisation seems to work fine.
I have removed and re-added the same folder under a different location with exactly the same settings, and this time it synced without any local additions.
Just for the record, the actual patterns are a little bit more complex than the sample given above.
What is interesting though is that even with those “local additions”, the folders themselves were still synced properly.
Just one last question, will there be any difference between using folder1*/folder2/** and folder1*/folder2/* in this case? Or perhaps even folder1*/folder2/?
There’s a mechanism in place, that should ensure that parents of un-ignored items are not getting ignored, but added like a normal directory. Would be very nice have a reproducer to find out where that fails.
. I still need the patterns though, as tons of other files get created in those folders, but I need to sync only a few of them. Fortunately, once the first Local Additions get solved by switching the folder type to SR and back to RO, the future synchronisation seems to work fine.
.