client should prevent data loss when excluding a folder

[jnweiger]

A prerequisite for #6715
Here is a case where a 2.5.0 desktop client deletes a file from the local folder that was never synced to the server:

• Connect to demo.owncloud.org
• Wait until sync finishes. One of the folders is called 'Photos'.
• Pause sync. click open the folder tree, remove the checkmark of 'Photos'.
• Hit 'Apply' nothing gets removed despite the warning, as the sync is still paused.
• Delete the folder Photos on the server. Nothing gets deleted locally, the sync is paused.
• Wait some time, forget about any potential traps here.
• Add a new file 'DoNotRemove.txt' to the local Photos folder.
• Resume syncing.
• The new file DoNotRemove.txt gets deleted. (together with the entire Photos folder).

Leave out any of the above steps, and the DoNotRemove.txt file is either preserved locally or even uploaded to the server.

[ogoffart]

(Moving to 2.6 as this is not a regression, and the quite complicated steps necessary to get the file deleted, which includes warning that the file will get deleted)

In theory, DoNotRemove.txt should keep the file from being deleted.

Edit: I can reproduce the problem. The first sync don't delete the files, but further sync deletes it as the parent directory gets deleted.

[ckamm]

I've tested this with 2.6's new discovery and can no longer reproduce the problem. The DoNotRemove.txt file is retained.

[ckamm]

I do however see a problem where the folder no longer shows up in the selective sync folder list, even if the contents are ignored "because of the selective sync blacklist".

[HanaGemela]

I also cannot reproduce the issue in 2.6.0alpha2 (build 12128) macOS 10.14.5.

I do however see a problem where the folder no longer shows up in the selective sync folder list, even if the contents are ignored "because of the selective sync blacklist".

@pmaier1 Please specify the correct behaviour. What should we see in the in the selective sync folder list?

[ckamm]

@HanaGemela Let's make it into a new 2.6.1 issue. It's separate from what this ticket was originally about, in particular it's much less severe since there's no data loss.

[HanaGemela]

@ckamm Done. #7316