When accepting a share the receiver should have the possibility to choose if that share should be synced to the clients.

[DeepDiver1975]

When accepting a share the receiver should have the possibility to choose if that share should be synced to the clients.

technically speaking we might want to add a mount option which allows visibility via webdav or not.

[DeepDiver1975]

@jancborchardt @dragotin

[PVince81]

Accepting a remote share (s2s/federation) ?

Does this also apply to accepting a local share ? (in the future we'll want to have even local users accept local shares)

[khoran]

I would also find such a feature useful. We will have several directories which will contain either very large files, or a large number of smaller files, and we would like to be able to ensure that no client accidentially tries to download such large directories.

[dcardin]

Although it says "at the receiver", I think that "at sharing" is also extremely valuable. I would like to have an extra checkbox that says "disallow sync"

[dcardin]

Is there any tracking/planning for such enhancements ?

[aquada]

I would also like to see this feature. For me it is just with local shares, but it would make sense for federation share also.

[PVince81]

This is similar to the request for disabling sync for folders #7909 or even more closer to disabling sync for specific ext storage mount points: #7234

Incoming shares, whether remote or local, are technically mount points.

[jancborchardt]

Technically they are mountpoints, yes. But humanly they are just regular folders. And unless otherwise specified, they should sync.

Of course yeah, we could have a way to disable automatically syncing specific folders. This should likely mirror the selective sync of the desktop client.

[PVince81]

I'd rather not have client-specific visibility as it require identifying clients.

Better is to have a special webdav property / permission that we can return to sync clients which tell them to not sync (in a nice way), see #26311

[michaelstingl]

@DeepDiver1975 @PVince81 @alleyoopster I was going through those issues with @pmaier1 , and we don't really get the use case. Which real-world problems are you trying to solve here? Could you elaborate?

[PVince81]

I suggest closing as duplicate of #26311 where a bigger discussion is happening

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.