Should syncthing sync the configuration folder?

Development
1

Continuing the discussion from ID same on two devices what happened?:

As noted in the linked discussion, a user unintentionally synced the syncthing configuration folder, including certs and then ran into trouble.

I think we can do more to either prevent this, or make it more obviously a problem.

Do we want to support syncing the configuration folder? Seems unlikely to me. What do you think about skipping those files (hardcoded, not in stignore) and emitting a warning?

Alternatively, syncthing could do the sync and emit the warning.

I would expect the warning to at least go to stdout/stderr. I’m not yet familiar enough with the events API to know how easy it would be to send a notification to GUIs as well.

2

I’d say its fine as it is. If the user managed to shoot himself in the foot, we can’t do much.

Perhaps I am syncing backups of my home directory, where syncthing the config dir has a genuine purpose.

3

We can distinguish that case: is the config dir in question the home directory of the running syncthing process?

Another option would be to display a warning in th GUI if a folder’s path contains Syncthing’s home directory.

4

Someone who cares enough can make a pull request.

5

I’d agree to printing a note or something, but it is a valid use case to sync your home directory to somewhere else. Maybe, potentially, we could flag it with a warning if not running in master mode?

(It’s also one of those cases we can never catch 100%, given symlinks and bind mounts and whatnot.)

6

As an st user I coudn’t agree more. The job of syncthing is to sync things as well as is possible. In my opinion making any sort of exception is very very bad (in fact one of the reasons I gave up using git annex assistant - another distributed dropbox-like solution - is that it wasn’t able to sync .git directories).

7

I sync configs because I would like to back them up so that I do not need to go through trouble of adding everything on multiple machines. However I put them in dedicated folders so that things do not get messed up.

I say ST should not care about what people are syncing. If user is syncing $HOME she should add syncthing to .stignore

8

Maybe a rule like “don’t replace anything in the config dir that’s currently being used by the current Syncthing process”? That letspeople back up home dirs, but stops Syncthing from happily nuking its own keys/config.

9

Again, that’s going to be tricky to be sure of given symlinks etc. Probably better to not try to give the assurance and do what the user says.

10

How about adding a section “Various Tips” and a subsection “Syncing your home directory” or similar to docs.syncthing.net?

If this is appropriate for docs, I could kick it off by describing there my own setup (symlinks to a subdirectory in ~/Sync), emphasizing what normally not to sync.

11

The problem is that most people don’t read the docs unless they’re looking for information. Someone who just sets up syncing of their home dir is unlikely to have read the docs.

12

Antony, wouldn’t it be better to have the gui wrappers take care of it? For example if you think that a small but still non-negligible proportion of windows users are irresponsible imbeciles ;-), then maybe you could implement the necessary preventive functionality in synctrayzor? Some small pop-up message like ''Synctrayzor detected that you are trying to syncronize your Synctrayzor configuration directory across your devices. This is generally not considered safe. Please press Get me out of this shit or I know what I'm doing‘’ and on pressing Get me out of this shit you would set up an .stignore file?

(Of course you should make the message shorter, so as to make sure the relevant demographics reads it :-))

13

I think it’s a fair punishment for them not reading the docs.

14

Since syncthing knows which config and key files is it currently using couldn’t they be made write protected by the current instance? So they could be synced out, edited by external editor but when ST tries to write over them an error is triggered and the folder goes out of sync?

15

I think users should be able to sync whatever they want. I also think it would be useful for the distro-specific wrappers like SyncTrazor to warn the user in certain cases, as suggested by @graboluk

You are right but how many times do you want to answer this question? I feel like I’ve seen it asked before. And for every user that asks, I’m sure that ten users hit the problem. Nine of those may give up and go back to proprietary solutions like Bittorrent Sync and Dropbox, and one may investigate and figure out the answer on their own. It’s obviously a pain point for new users who don’t bother to read the config.xml and the docs first. And I think that in the end, Syncthing should be easy enough for those users. Else why even offer the web GUI when editing config.xml and tailing the logs is so much simpler?

16

On the other hand, we will have people coming and complaining that their are syncing their user directory to an offline/cold storage location, and they constantly gets slapped with these warnings or restrictions for doing things that they genuinely intended to do.

If people find it hard to or are ignorant enough not to read the documentation to solve the issue, then let them be someone else’s problem :smiling_imp:. I don’t think we are in a position to compete anyway.

If someone makes a reasonable PR, I am sure it will get merged, but you have to think about both ends of the spectrum.

17

That’s why I think the distro wrappers should handle it. For example, SyncTrazor could warn the user the first time, and they could click “I know what I am doing”, and they would never be warned again.

I wonder, does forum.syncthing.net record the browser fingerprints of users? You could see which OS people are having trouble on and ask the authors of the distro wrappers to implement this :wink:

18

Plenty of people use syncthing without a wrapper of some sort (from my metrics, I’d guess well over half). Those people are also the people least likely to read docs (since its the docs that contain the list of wrappers).

Also bear in mind that by the point that SyncTrayzor notices that there’s a problem, it’s too late: the configuration has already been saved. Combine this with the fact that, IMO, the only sensible place to put this check is on the receiving side (“don’t overwrite your own config”), and the wrappers are starting to look like a less sensible place to put a check like this…

19

Pull request for emitting a log statement: https://github.com/syncthing/syncthing/pull/2391

20

Sorry for pushing this again but no reply to my previous post :slight_smile: I know that syncthing does not lock config files that it is using (so external editors can be used on them) but is it too hard to add a list ot files that the synching part should not write to? Like the config file it is currently using, the appropriate key files, the app file itself (which is locked by the OS I think but anyway) and any other that are know to break the current working configuration?