Tips and Tricks (!?)

Well, I know there is a “Tips and Tricks” badge for these kinds of things. I was wondering, if some of the things I do with syncthing (successfully, I might say) are considered “dangerous” or “bad practice” and would like to hear opinions.

DON’T use this as a howto (yet), as I am not sure these are a good idea.

1.) Adding .stversions as (unshared) repo

Useful for: Slow bandwidth connections

Not recommended for: Machines low on RAM

This I did on some machines because while restructuring my Picture-library (renaming huge folders) syncthing occasionally deleted the folders instead of renaming them. Since the machine in question was behind a low bandwidth connection, I made use of syncthing’s ability to share data block between repos. This way I managed to get the files back much faster.

The good:

  • I won’t need to transfer the files again if syncthing messed up
  • I won’t need to transfer the files again if I messed up

The bad:

  • The amount of RAM might increase drastically, depending on the size of changed files and the time to keep these files.
  • (?)

2.) Symlinking the database folder… (…and share it in an Multiboot Environment)

Useful for: Multiboot Environments, Machines with a small dedicated System-Partition

Not recommended for: “default” Setup, with “Sync”-folder at ~/Sync

So, I keep my Linux installation on a fairly small partition (say 30 GB), while Windows lives on about 4 times the size (and still isn’t happy), the Rest of my hard drive is a dedicated “Data” partition. Syncthing’s database sometimes grows without measure, eats up all my space on my small system drive (regardless of the OS) (20+ GB) and lets syncthing stop when the drive is full. Also, I have the database twice (Few GB) on my system with essentially the same data. So now I share the database on my “Data” partition, which is much larger anyways.

The good:

  • Saves space (and CPU-time) by not duplicating the database
  • Actually helps Syncthing to do its job in certain scenarios
  • Keeps your .config folder free of a multi-GB Database
  • One is free to choose the location of the database

The bad:

  • One must be careful to have “identical” setups on both OSs (Syncthing does not ensure this but will delete any “superfluos” data in the database)
  • Careful: Repos actually have to be the same actual folder (e.g. not each at ~/Sync)
  • Can be tricky to set up
  • (?)

@AudriusButkevicius: I got this tip from you, but in a recent post you were somewhat critical about the idea yourself (?)

3.) Sharing the certificate on multiboot machines

Useful for: Multiboot Environments

Certainly not for: Virtual Machines, your complete device-zoo sharing the same certificate

Somewhat obvious and related - since the OSs cannot run simultanously and probably have the same repos.

The good:

  • You won’t have several nodes which correspond to the same machine in your cluster
  • With introducer feature on- you won’t have a node in your config that corresponds to this very same machine

The bad:

  • (?)

I’d like to hear some qualified opinion on this, so it might end up in a “Tips and tricks” area of the docs, alongside with “ssh-tunneling to syncthing” and the somewhat misplaced “Reverse Proxy Setup”

Maybe somebody else has a secret trick he or she’d like to share?

This is really clever.

Mind linking where, so I could recall what it was about to figure out the context?

You suggested it in my ticket here

and implied scepticism here (works great btw)

But maybe it was just an honest question and I misunderstood :slightly_smiling:

reminds me of this :wink: