I’m testing a fresh install of nearly 190k files in 20k folders for a tiny 339GiB size.
This folder is on a windows 10 computer.
I connect two others windows 10 computer to this share, each with a different list of exclusion.
The two computers are syncing normally only the files and folders within the exclusion list.
The thing is if I put a new file inside a synced folder then it doesn’t sync back to the root computer.
Initial Computer with all files (Syncthing in 2 ways sync):
* Folder 1111
* Folder 2222
* Folder 3333
Second computer (Syncthing in 2 ways sync) with exclusion list
So the folder 1111 is synced
Third Computer (Syncthing in 2 ways sync) with exclusion list
So folders 2222 and 3333 are synced on this computer
If i put a new file in the folder 1111 of the first computer then the file is normally synced in the 1111 folder on the second computer.
But if I put a new file or modify a file inside the folder 1111 of the second computer then it doesn’t sync back on the first computer.
I tested this behavior with only two computer then the files are synced 2 ways like they should. But with the combination above in 3 computer sync it’s not working.
I could see a possible scenario that could (but of course shouldn’t) cause this. (Paging @imsodin on the thinking.)
Device B: sees new file, scans it, announces it to A and C
Device C: ignores the new file, sets the invalid bit, announces to A and B
Device A: gets the announcement of the file from B and C, the one from C has the evil bit set, and somehow ends up as the frontmost file in the global list. Device A does not attempt to pull the file because it is deemed invalid.
Maybe this is order dependent or something on A.
We should make sure that given both valid and invalid variants of a file the valid one always wins. I’m not 100% certain that we do.
That scenario should not be possible: An invalid files should always lose to a valid file with the same version. As file from B announced to A is valid, it should win over the file from C with the same version but invalid bit set.
I checked the code and there is one loophole, but I don’t think it applies to the situation here: When files are in conflict, normal conflict resolution happens (i.e. checking delete flag and mod time, but not invalid), so an invalid file might win over a valid one in that case. I’ll fix that.
So the problem is locally on just that device. To clarify: Device B has the exact exclusion list you wrote above and you create a file at “16640/newfile” and that does not get scanned (file counter doesn’t increase)? You can enable the scanner debug facility, trigger a scan and check the logs for lines with the name of the file you created.
I can confirm that both your exclusion list and mine are producing the same effect.
If I remove !/*/16640* from the exclusion list on Device B then it won’t sync again this folder but the files will remain on Device B even if it’s now exclude from syncing. What I wanted to know was if it was the expected behavior or if syncthing should delete the files on Device B (which is in fact what I want to achieve)
This is in exclusions list as an exclusion from exclusions, so it is an inclusion. Removing an inclusion, as far as it is not re-introduced lower in the list turns it (as included in final general * exclusion) to be excluded. Then ST just ignores matching items. Beside of this we hope st won’t deleted (nor sync) anything on its own, namely won’t delete (nor sync) anything if it is not instructed to do so from a remote device. From a local POV, adding or removing ignore pattern won’t be itself the reason for deletions. The reason would be missing files/dirs on the other side once an exclusion is dropped.
How do I do :
I include locally
1a) I work on files and let sync
I remove inclusion locally
I delete locally what I don’t need locally anymore.
In you case your 1640 thing will match the general exclusion, so will be ignored. ST won’t sync local (nor remote) 1640 so you’ll need to manually delete it locally if you don’t need it. Deletion won’t be sync’d