Looks like syncthings fork of the library already got updated but syncthing still uses an older version of it: syncthing/syncthing/blob/a5bbb500e62c3742ef0860a9f21395575a1162b9/go.mod#L44
Not sure if of any use, but this is a DEBUG log of what happens after adding a new text file to test2, which then triggers a scan of test1 (which itself is empty). Still, I would say that the behaviour is at least quite interesting. Fortunately, it doesn’t seem to actually add any of test2 changes to test1, so I don’t think that there is a security risk here. Basically, file watcher will be triggered by changes in test2, which will then make Syncthing scan test1 and this way detect changes there. I have decided to do one more test, just to confirm my assumption of file watcher being tied to the original folder.įollowing from point 3 in b), if you add/modify/delete files inside the test2 folder (which is the original test1 folder renamed), this will actually make Syncthing scan the test1 folder.
GitHub, but in my case the subfolder seems to continue picking up changes fine, so the two issues may actually not be related.I have also tried following the exact steps listed in No watcher events received for items in a deleted then recreated subdirectory I have no idea on how the internals work, but it seems that file watcher is tied to the physical folder itself, regarding of its actual name/path. It seems that renaming the folder back and forth doesn’t break the watcher, but creating a new copy of it, and then replacing the original does. Watcher starts working again only after restarting Syncthing.Pausing and resuming the folder doesn’t help.On the disk, create a copy of test2, and rename it to test1.On the disk, rename test1 to test2, and then from test2 to test1 again.In Syncthing, add a new folder test1 with file watcher enabled.I have tested two cases regarding the root folder. The issue seems to be a little more complicated than I thought before. Just for the record, I couldn’t find anything useful in the Event Viewer either, and also the files themselves have actually changed content and/or mtime too, and the watcher does detect them under normal circumstances with no issues. This is kind of a big problem for me, because I normally set the rescan interval for my folders to 86400, as I just have too many of them to keep them being scanned every hour, but with a broken watcher this also means that changes may be delayed up to 1 day, which is very bad.
#Filewatcher windows manual
Only a manual re-scan forced them to be detected and synced. I could easily know it, because the last scan date was not changing, even after modifying plenty of files. File watcher still didn’t work for the folder later on though. Right now everything is working properly, but when I had the issue for the last time around 2 days ago, pausing and unpausing did help, but only in a way that it triggered a rescan, which then detected the modifies files. Restarting the folder (pause, unpause) doesn’t help?
0 kommentar(er)
