I’m trying to use Syncthing to synchronize my files and essential configuration between my primary and secondary workstations.
The configuration includes many disjoint directories, so I’ve added
~ to syncthing and wrote a whitelist-style
.stignore file that unignores specific subdirectories I’m interested in and ignores everything else:
// .stignore -- include a sub-stignore that would be synchronized
// .stignore.work -- ignore all except "work" (unique files and work-critical configuration)
In this configuration, syncthing still tries to traverse and watch ignored directories:
### Filesystem Watcher Errors
For the following folders an error occurred while starting to watch for changes. It will be retried every minute, so the errors might go away soon. If they persist, try to fix the underlying issue and ask for help if you can't. [ Support](https://forum.syncthing.net)
Work error while traversing /home/intelfx/.local/share/containers/storage/btrfs/subvolumes/3c79994778fb741aa2e2abf3194d013b369878814dc5e6e1860ece34481ba321/var/cache/apt/archives/partial: permission denied
This apparently also causes syncthing to constantly hog 100%CPU, probably because it tries to repeatedly traverse
~/.local (a huge directory tree) each minute.
I do not want syncthing to look under
~/.local, ever. How do I set up syncthing to do so?
The problem is with the “watching for changes” feature and include (
!) patterns, specifically this one:
In order to find all included paths, Syncthing still traverse the entire file tree, even if a parent is ignored. Otherwise
/.config would be ignored and
/.config/gcloud missed. The only exception to this rule are “toplevel includes”, i.e starting with a path separator and not containing any path separators or double asterisks.
Now for our own scanning periodic logic, we can ignore errors on ignored directories, however in the filesystem watching library we use any error is fatal.
Your options are to either find patterns/directory structures that only need top-level include directories or you disable watching for changes (periodic scans will still traverse your entire
.local dir then).
Hm, so do I understand correctly that even one non-toplevel include pattern (
/.config/gcloud) causes Syncthing to disable optimizations for (and traverse) the entire tree and not just the relevant toplevel directory (
/.config in my case)?
Yes. Not saying that’s a necessity, just a decision for simplicity.
Alright, thanks. I guess I can live without
~/.config/gcloud however it’s pure luck that e. g. kubectl does not follow XDG and stores its configuration in
~/.kube rather than under
Would it be worth it to report this as a RFE, or is this behavior unlikely to change?
You can certainly file it, it “just” requires a smarter ignores optimizer. In the grand scheme of things I suspect this is low priority for most people currently hacking on Syncthing, but you never know.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.