Client: It is allowed to sync the root node and any number of subfolders in a different sync folder connection if you invert the order of creation of these

[SamuAlfageme]

Expected behavior

As pointed out by @TDannhauer in https://github.com/owncloud/client/issues/5305#issuecomment-260888131

It is not allowed to sync the root node and additionally only a subfolder in a second sync folder setup.

This is what happens as long as you sync the root node first:

To maintain this behavior the root node should not be available in the list after setting any subfolder sync connections.

Actual behavior

Doing it backwards: creating first any number of subfolder sync connections and then one with the root node is possible and does not disable the button on the GUI even though it's not possible to continue creating Folder Sync Connections.

Steps to reproduce

1. Create a Folder Sync Connection of any subfolder
2. Create one with the root node
3. (Optional) Repeat 1 (the button is not disabled, but the wizard displays the usual warning)

[TDannhauer]

Well, I'm absolutely not happy with neither this bugreport nor the discussion in #5305.

In my opinion is is annoying paternalism to artifically limit the ways you can use the client/system.
We should serve the needs of the user instead limiting the oportunities of a technical solution.

So what are the basic needs?
Following all related discussions, it seems that some|many|all users want to sync the whole repo AND parts of it into several local folders. fullstop. Let's orient on that need.

Whether we technically do it by
a) allowing multiple identical accounts with always only subfolders OR the root folder
b) or allowing only a single identical account but multiple local sync folders irrespective whether they are root or sub folders.
doesn't make a relevant technically diferences.

The only argument in all discussions I can agree is "lets make it as simple as possible for non tech users". That should be a main goal. And it is the simplest usage if the system behaves intuitive and as expected.

My warm recommendation for the whole story is to remove all artificial limitations (like the one proposed in this issue) and make things easy. If a user wants to add another local sync folder: allow it. He has entered already the credentials for this account, why forcing him to do it again for another account? He wants only a second folder! give him a second synchronized folder - and not a second account.
If the user wants to add another identical account? Let him do it! We doen't know the reason, but we are also not interested in the reason for the first account - why interested in the reasons for the second one?

We should neither limit the numbers of identical accounts nor the limit of local sync folders - may it be root or not.

Imposing limits on synchronizable local folders is not intuitive. Adding a second account to work around that even less.

Of course, syncing data in more than one local folder may include data duplication. Do we know whether it happens on purpose or by accident? No. Duplicates may happen on every system - on clouds as well as with pure local data. Its a matter of data management. If someone mismanages his data, he may get duplicates may it be local or in the cloud. But this is imo absolutely no reason to implement any kind of limitation.

We should not presume to know the "only" way how to use the system. There are multiple ways and all of them have their special justification. Let's be a _free_ software, remove limitations and let users use the system as they need.

We should be enablers, not disablers. Allow it instead of technically limit it.

Sorry for the harsh words, but I think OC client is going the wrong route and we should reflect on that.

Torben

[hodyroff]

We are with you on this design principle. Still of course we must prevent bad things to happen and restrict things in some rare cases where we have no better solution at a given point of time. So it sounds like we can close this one? @SamuAlfageme ?