Best practices for directory structure

Hi All:

I’m new to Syncthing and trying to use it to replace Dropbox, Google Drive, and other public cloud sync services. I’m trying to figure out the best approach to setup my directory structure across devices so I don’t end up with recursive or circular directories being synced.

Basically, I have a work laptop, a personal laptop, and an Android phone. I’ve been using Dropbox for things like syncing my Todo.txt/done.txt in SimpleTask, syncing a password database, syncing my Joplin DB, etc.

I want my work files synced to my personal laptop, but not the other way around. My Todo.txt, password DB, and Joplin files should be on ALL devices (laptops and phone). I’d also like to sync all pics from my phone to my personal laptop.

I can’t really setup one big sync folder because then I’d end up with all my personal files on my work laptop as well.

Is it best to have separate folders for each thing (todo.txt, password DB, pics, work files, personal files, etc, and set them each up in Syncthing separately? Then I could have one main Sync folder that syncs across all devices so I could just drop stuff in there temporarily that I need to share.

So I guess I’m just looking for some suggestions or examples on how to setup my initial directory structure so I don’t have to fiddle with it later.

Thank you in advance!


The nice thing with Syncthing is that you can share stuff at any location with just the devices you want (well not really on Android, if you use external SD cards, but that’s a special case). More or less you can organise your files/directories such as it fits your workflow best and than share just the parts you want with the required devices. That potentially means you need to use ignore patterns to exclude things you don’t want to share with work.

Thanks @imsodin! I was reading in the FAQ that you shouldn’t share a folder that’s inside another folder that is already being shared.

I tend to always keep ALL data files in C:\Data on whatever machine I use (well, until I switch to Linux. LOL!). Anyway, so I guess inside of Data I could then have Todo, PasswordDB, Joplin, Pictures, and SharedSync, and then share each of those out individually in SyncThing.

I think we should relax this recommendation a bit, or document just the specific things to avoid. For example, I have a layout like this one my home file server:

  /photo   -> shared send-only with another server
    /2019  -> shared recv-only with the desktop & laptop

This is perfectly legitimate.

However, there are disaster scenarios.


/files       -> shared with Bob
  /documents -> shared with Bob


/documents -> shared with Alice
  /files   -> shared with Alice

Syncthing will try to duplicate the looping structure until you run out of disk space. Don’t do that.

Sharing the same directory twice with another device, as two different folders that point to the same directory on the other device, is probably also a bad idea. I can see there being update ping pong potentially forever.

But enumerating all the wrong things is hard, hence the general recommendation to keep things simple. :slight_smile:

1 Like

Thanks @calmh, that helps a lot! I think I need to keep all my directories separate and simple. Under Data, I could have a Work-Docs and Personal-Docs, and then all the other ones I mentioned. That should solve the problem.

Also, syncing dbs (if they are actual dbs) can lead to corruption or conflicts, as they are not meant to be synced and do not handle concurrent access.

1 Like

@AudriusButkevicius I’ll keep that in mind, but I don’t think they are actual DB’s. One would be a keepass DB file, and the other would be the files Joplin syncs to the local file system. I’ll have to test with Joplin to see if Syncthing causes any issues.

Rather than creating several shares for various files in one folder, you could share the whole folder and exclude those bits, which you don’t want to share.

Have a look at .stignore:

I found this thread very useful, as well:

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