Selective Sync Feature(most important)

Except the first few need to be prefixed with an exclamation mark (!)

1 Like

But according to my understanding it is either or (?). Either I have an Ignore list or a Positive list with a complete exclusion of the rest with "*", or?

1 Like

You can do whatever combination of includes and excludes you want.

1 Like

So it sounds to me what’s really being requested it looks like is a graphical way to manage the ignore list based on global state. I envision a tree structure with checkboxes to select for sync (or select to ignore).

IMO even just a way to VIEW the global state would be a huge boon. Presently knowing what’s there requires syncing the full contents of everything, which has proven for me and those above to be non-ideal.


Would there be any way possible to put a folder advanced option which leads to receive the global state and indexes first, then halt and will wait to start transferring files around until a .stignore file has been created? A wrapper could then present the global state to the user, the user select what he/she wants, .stignore will be created and then files are synced.

I was thinking about a similar thing, some kind of half-paused state for the folder. It should exchange index data and make that available for e.g. inspection through the API endpoints. But actual content transfer (pullers) would be halted. Possibly also block requests from remotes to pull our blocks?


Putting * into .stignore initially does achieve just that, doesn’t it?

1 Like

Not quite I think, as it will prevent the local state from being populated. While pausing pullers and blocking requests will only stop the transfer. Guess it depends on whether we want our local state (index) to be sent to other devices or really just examine their view of the global state.

1 Like

I don’t see how that matters, that’s an implementation detail to me. The use-case here was to get a view of the global state to be able to choose files before syncing them - that works, right?