Personally, I don't think it gets much easier than including a global sync file though, apart from your suggestion to mimic the way git does it, although this would have its drawbacks too - for example, " if user does not want it synchronized, he can add. stignore's per peer, with the included file path pointing to the dynamic/synchronized list.Įdit: I see another user has already applied this approach: Įdit 2: reading your post again, it seems you are already aware of these methods but are looking for a more convenient way of implementing them during initial setup deploy. stignore also supports #include, so you could have static. As long as it follows the symlink correctly, I don't see why this workaround shouldn't work. From my experience syncthing does not need to be restarted to apply changes to the. That way if you edit the synced_ignores file it will synchronize across all the peers as normal. stignore file to instead point to /abc/synced_ignores for example, for all the peers. Let's say you're syncing a folder /abc/* on both devices. The ignores will only remain a list of extensions we ignore, rather than paths with magic wildcards like we have now.ĭoes that mean users won't be able to exclude file types from specific folders? But it's complex and requires a lot of work for users. And one would need to make it work on different OS (Win, Linux, Android.). That script also should deal with multiple syncthing instances on some machines with different port numbers (multiple users on the same machine.), credentials. st_ignore_synced.Īutomating via REST API means the user would have to make sure that a script gets called at certain points of time (syncthing start, adding new repository. It would be even trivial, if #837 would add the line #include. Making Syncthing support to sync an additional ignore-file would be no task for you guys. It is better to have a simple solution to a simple problem. Also please consider how error prone it is to let the user take care of adding ignorefiles to each repo of their machines or to let the user even automate that. Just because you can automate something doesn't mean a native implementation wouldn't be useful. It is about reducing the amount of having to re-enter (manually or by scripting) redundant data. This is not about using syncthing in a large cluster. What would a script adding the line #include st_ignore_synced.txt to every repo on an instance look like? I know Linux bash and Windows cmd, but looking at the API documentation I don't know how to talk to Syncthing's REST interface over HTTP on the GUI port. I've heard of the API (you are talking about this? ) however I don't know where to begin. When you redo the ignore system, please don't kill that feature. What I really like about it is that I can ignore folders/files/pattern unix style like /folder_a/file* and it would still work on Windows. I didn't know you want to redo the ignore system. stignore file for all repos, meaning you have to include machine specific stuff in another external txt file and whooops we have a st_ignore.txt and a st_ignore_synced.txt - just what I proposed in the first place. Additionally, this would mean you have to use the same. It reduces the amount of work, but the work is still useless.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |