# Completely prevent syncthing from traversing a directory subtree

**URL:** https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060
**Category:** Support
**Created:** [May 25, 2020, 5:15am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060 "2020-05-25T05:15:27Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![intelfx](https://forum.syncthing.net/user_avatar/forum.syncthing.net/intelfx/32/8024_2.png) [@intelfx](https://forum.syncthing.net/u/intelfx)
#### Post date: [May 25, 2020, 5:15am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/1 "2020-05-25T05:15:27Z")

</div>

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
#include .stignore.work

```

```
// .stignore.work -- ignore all except "work" (unique files and work-critical configuration)
!/Documents
!/devel
!/.gitconfig.*
!/.profile.*
!/.kube
!/.config/gcloud
!/.stignore.*
*

```

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?

---

<div class="post-metadata">

### Author: ![imsodin](https://forum.syncthing.net/user_avatar/forum.syncthing.net/imsodin/32/3317_2.png) [@imsodin](https://forum.syncthing.net/u/imsodin)
#### Post date: [May 25, 2020, 5:56am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/2 "2020-05-25T05:56:09Z")

</div>

The problem is with the “watching for changes” feature and include (`!`) patterns, specifically this one:

```
!/.config/gcloud

```

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).

---

<div class="post-metadata">

### Author: ![intelfx](https://forum.syncthing.net/user_avatar/forum.syncthing.net/intelfx/32/8024_2.png) [@intelfx](https://forum.syncthing.net/u/intelfx)
#### Post date: [May 25, 2020, 6:13am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/3 "2020-05-25T06:13:28Z")

</div>

@imsodinHm, 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)?

---

<div class="post-metadata">

### Author: ![imsodin](https://forum.syncthing.net/user_avatar/forum.syncthing.net/imsodin/32/3317_2.png) [@imsodin](https://forum.syncthing.net/u/imsodin)
#### Post date: [May 25, 2020, 6:22am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/4 "2020-05-25T06:22:00Z")

</div>

Yes. Not saying that’s a necessity, just a decision for simplicity.

---

<div class="post-metadata">

### Author: ![intelfx](https://forum.syncthing.net/user_avatar/forum.syncthing.net/intelfx/32/8024_2.png) [@intelfx](https://forum.syncthing.net/u/intelfx)
#### Post date: [May 25, 2020, 6:24am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/5 "2020-05-25T06:24:03Z")

</div>

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 `~/.config/...`.

Would it be worth it to report this as a RFE, or is this behavior unlikely to change?

---

<div class="post-metadata">

### Author: ![calmh](https://forum.syncthing.net/user_avatar/forum.syncthing.net/calmh/32/15311_2.png) [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [May 25, 2020, 6:28am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/6 "2020-05-25T06:28:41Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![system](https://forum-uploads.syncthingcdn.net/original/2X/0/0b50e0a202b22ae6a67190759e8c868805b8ed9f.png) [@system](https://forum.syncthing.net/u/system)
#### Post date: [June 24, 2020, 6:30am UTC](https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060/7 "2020-06-24T06:30:06Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
