New modifier "exclude from this device for the moment" for .stignore

Hi everybody, I started using syncthing to replace dropbox. Unfortunately is has some huge downsides. Because of my limited space on my hard drive and very complex folder structures, I can’t always keep everything on my local disc. So I need either to create a few thousand folders without hierarchical structure (not an option for me) or think about a very very smart hierarchical structure and sync just the top most 1 or 2 levels, to keep it to a manageable sync folder count. Until I realized that the used disk space is not distributed even in my logical hierarchy…

Then I wanted to use .stignore files to exclude files/folder (within a sync’ed folder) from sync and resume it later on (see How to resume syncing an ignored folder that does not exist on my device?). Unfortunately it’s not possible with syncthing.

It seems to me that dropbox, different than syncthing, is collecting file events (like created, deleted, renamed, moved, etc.) and is able to replay these changes then on other devices, which makes it very handy and efficient. I know this comfort is not possible with syncthing (especially regarding traffic efficiency) but I would at least like to be able to exclude and resume folders from syncing without managing hundreds of folders without hierarchical structure in a browser window GUI.

How about introducing a new “exclude from this device for the moment” modifier for .stignore. So when I set it, the files and folders should be deleted automatically on my local device but stay on all other devices. As soon as I remove the line, it’s getting restored on my device.

GUI implementations for syncthing could later on show folder structures with checkboxes, and set the path in the .stignore file automatically based on the user “uncheck” clicks. It would be similar to dropbox then.

Thanks for your attention.

PS Screenshot of Dropbox GUI image

There is already a ticket for something like that, sadly the hard part is UI and nobody picked that ticket up in years.

You could potentially bodge something with receive only folder, which does not send its deletions out, and has a “revert everything back” button

The GUI is not as important as another modifier in .stignore :)! But it would be good for mainstream adoption, true.

Unfortunately this workaround is everything else than elegant. I came with help already to this workaround for the moment, but I really do hope that it will be implemented. Why? It’s one of the first features a user is looking for when he has lots of folders and data… Being not able to offer it, can be a killer argument.

Well it’s a killer argument that has been there for 5 years, so don’t get your hopes up.

Sounds like “syncthing” is a product as is… no roadmap or further improvements planned… except of a new web GUI (why? lol) according to an announcement. Seems that I may need to check NextCloud sync or Seafile again. Too sad. :unamused:

You can always be the hero we need, step up and implement it…

It’s a product as is, managed by volunteers during their free time, noone is paid to do this, so I don’t really see the incentive for me to commit my evenings to deliver some roadmap.

Biggest reason this killer feature is not there is because the effort that will be required to build a UI for the selection of folders. So yeah, UI rebuild, why lol…

3 Likes

Sorry my post was a bit accusatory…

I would (as developer) but I’ve never used go so far and I have no clue about the implementation history/architecture yet. And to jump into a new technology/architecture it takes way more time. And every open source project has it’s own guidelines and community, so if it conflicts with the maintainer’s opinion, it will stay a fork forever.

Well I don’t see the UI as priority 1 (but yes as said: for the mainstream usage for sure). The biggest issue for me is the ability to configure it somehow.

I wonder if it would make sense to create donation pools for specific features… or a business model. Because it seems to be a great piece of software but to get a step further, a fair and viable business model would be not too bad to create incentives for developer.

Nor did I before I started contributing to syncthing.

Sure, but that is why there is a process behind it, PRs, reviews, etc.

Learning new tech is generally useful, and this is not a massive project where there is noone to hold your hand and guide you through it.

It’s normal for every user to think their issue is the most important, as thats is what they are unhappy with.

We, as maintainers see the “most important issue” across multiple users and can draw a bigger picture. As it stands, we believe the biggest issue that causes users to not use syncthing is the poor UX due to UI. Sure, features in question are nice, but these affect single digit percent of new users.

I don’t think $200 bounty will suddenly become a big enough of an incentive for someone to spend weeks of their free time implementing something, and it’s unlikely to ever be a big enough of a money pool to actually be an incentive.

We use bountrysource, and the biggest bounty is $2000 or so, for something that is a fundamental change in the protocol with potentially weeks of effort required.

The best incentive is to need the feature so badly that you end up spending your own time contributing it.

Regarding business model, the whole purpose of syncthing is to be trustworthy and open, and at any point there is a business model, it becomes closed source and questionable trustworthyness.

1 Like

I am unsure what you require though? There’s a bug/limitation currently, which can lead to deletions of ignored data propagating to other devices when unignoring instead of conflicting and thus resurrecting local files. I actually intend to look into fixing this soon (if my current theory works out it’s a simple change, otherwise it touches a pretty central and sensitive part - so not something to change lightly). I just looked into it and naturally the easy way doesn’t work/has equally bad limitations -> the “full-blown”, hard solution is required. Well, maybe there’s also an intermediate solution (I should type slower and think faster).

On a tangent: Except for a bit of python scripting for data-mangling in my Physics studies I didn’t program at all before joining Syncthing and another project in C++/QT - and after a year or two it was decided that I was trustworthy enough to become a co-maintainer. From my limited experience Syncthing’s code is extremely understandable and well separated, so you don’t need to dig into almost everything to fix one thing that your interested in.

1 Like

Totally agree!

Depends on the project, but this one seems to be well set up.

Indeed. But I’m not sure if a simple browser GUI will fix it. I for my part needs also overlay icons in my explorer that shows the status of files/folders. Using a WebUI alone will not suit my needs. But thats why there are projects like https://github.com/syncthing/syncthing-gtk, that are unfortunately not maintained as I would wish (and it’s duplicating functionality from the WebUI for no reason). So the solution here (IMHO) would be a very basic project for OS integration with app sync indicator icon in the OS status bar and proper overlay icons and context menu for different file manager on different OSes. This could then be combined/linked with a proper web GUI (ideally put in a html5/js native application, without a browser address and favorite bar).

I would need the option to resume (=download) an excluded folder after removing the exclution (without the need to touch all files on another device OR the need to set my folder temporarily to receive only - latter eventually will not work anyway?)

I will see how it’s going. But right now I cant spend weeks to dig into the project for the implementation. I made a short check but it’s not as easy to as I thought in the first place. But eventually I will get back to this issue later. For the moment I need to test my workaround, or choose another setup :-\

As I mentioned that should be possible and will be in the next release, see https://github.com/syncthing/syncthing/issues/6038

Sure, sounds awesome. I just have my doubts about the “basic” part.

Well the GTK already implemented most of the functionality, it just implemented too much, means it should be reduced and made more lightweight. Instead to open a GTK window/settings it should just open the browser. And the file system overlay is not respecting the .stignore file yet. This is very unfortunate in combination with this here discussed issue.

This is a great news! Yes this is exactly what I was asking for! :slight_smile: