Repository navigation
Add Webdav property to advise the sync clients to not sync this entry #26311
Description
There are several tickets that propose different approaches and different criteria for sync exclusions.
Regardless of the criteria, I think the basic mechanism should be that the server returns an extra Webdav property <oc:do-not-sync>1</oc:do-not-sync> to tell the client to not sync this item.
It is then the responsibility of apps or whichever code that decides what the exclusion criteria is to set the property on the entries.
This is purely the backend/protocol level.
Some proposed criteria that would need to be implemented separately:
- excluding external storage: Feature Request: ability to exclude external storage mounts from being synced by sync client #7234
- exclusion by user/group: [Feature Request] define groups for excluding mounts/folder from beeing synced (by client) #25873
- pattern-based, similar to sync-exclude.lst: enhancement idea: Global sync-exclude.lst #19385
- exclusion by patterns: Allow list of sync exclusions to be managed from the server (including whether to sync hidden files) #22607
- "certain directories": Disable synchronisation for certain directories #7909
- excluding federated share individually from sync: When accepting a share the receiver should have the possibility to choose if that share should be synced to the clients. #14727
- excluding individual ext storages from syncing: config option for external storage #12216 (see sync option)
@owncloud/filesystem @guruz @ogoffart @dragotin @davivel @DeepDiver1975 @butonic
Activity
PVince81 commentedon Oct 7, 2016
I'd even go as far as to say that these different criteria should be implemented / implementable as apps, which means that core needs to provide hooks (for sabre plugins?) for apps to be able to decide which entries to exclude.
PVince81 commentedon Oct 7, 2016
then people can really go crazy with any custom use cases 😄
PVince81 commentedon Oct 7, 2016
cc @pmaier1
mmattel commentedon Oct 7, 2016
Thanks for taking care of !
When going for an implementation, an idea is to (re)use this mechanism with federated sharing where you can forward the webdav property from the source - end to end. Like a fed-sharing checkmark in administration "forward no-sync webdav property". (Sorry full of ideas 😄)
AnrDaemon commentedon Oct 8, 2016
Keep It Simple and Stupid.
Return HTTP/1.1 403 forbidden for files you deem undesirable for sync. You could add a header explaining the reason, so that a compatible client don't frek out and reduce this specific issue to a mere notice instead of sync error. But the first reaction must be clear that the action attempted is not permitted.
PVince81 commentedon Oct 10, 2016
@AnrDaemon The problem with 403 is that not only sync clients use Webdav. And I don't think we should do user agent checking to do conditional blocking.
Also in some cases a client could want to still get the metadata to be able to display it in some way without syncing, like for the folder selection dialog in the desktop client or like for the mobile client which only syncs whatever was marked as "make available offline".
Another name for this new Webdav property could be "sync permission" for people who prefer that name. 😄
dragotin commentedon Oct 10, 2016
We could do that, but my concern is that people will fail to understand why some things are synced and others not. How do we get that reasoning to the clients?
First reaction might be to add a string to the XML explaining that. That is hard to do because of translations. It would mean that clients need to send an accept-language header with propfinds and the server needs to parse it in case. Not sure if that is expensive or not. Probably we can do that, but I am not sure if there aren't better alternatives.
...
PVince81 commentedon Oct 10, 2016
Who ? The sysadmins, the developers from third party clients, or the people using the desktop client ?
For the desktop client, there's the sync tab about "Not synced", so the skipped entries could be added there with the reason "because the server told us so!".
pmaier1 commentedon Oct 10, 2016
https://github.com/owncloud/enterprise/issues/1594
ogoffart commentedon Oct 10, 2016
So we would check this property only for new folders? and we would still allow the user to check it in the selective sync? So it would be a default off for selective sync?
PVince81 commentedon Oct 10, 2016
@ogoffart hmm, good point. I actually forgot about selective sync and was thinking of a "hard" way of blocking syncing, basically that the desktop client would refuse syncing any of these folders.
Yeah, but maybe you're right that it should rather be a suggestion that preselects (or pre de-selects) folders using the selective sync feature.
PVince81 commentedon Oct 10, 2016
added these to the list in the main post:
That's already quite a few use cases 😄
PVince81 commentedon Oct 10, 2016
Seems there was already a client ticket, linking here owncloud/client#4621 😄
30 remaining items
mmattel commentedon Oct 26, 2016
Most of us look to the examples from a very high knowledge and experiene level. Ordianry users do not use curl or any other technology which needs deep knowledge and understanding. They do not even know that these things exist, and just use it and want to use it as a no-brainer. Give them access with the browser, they use it, give them access with a client (sync or dav), they use it. They do not want to spend a lot of brain into it that is not their focus. All users do understand if the admin says, use the browser, use the (dav) client, this is what you can post configure and this is restricted and you can not change for what reason ever. 99.9% of the users do not change or try to fake the standard settings, maybe they ask to be granted access but not more. This causes much less post work to the admin and the users as they just work and do not want to tinker. Just my opinion, based on experience.
AnrDaemon commentedon Oct 26, 2016
That's how the fall starts. First you separate people into "ordinary" and "some other", then you point to a chosen group and say "look, they are not complaining and very content with features we provide, we should continue in this direction". That's how Windows 10 was born.
guruz commentedon Feb 7, 2017
FYI The 2.3 client has an option now "Ask for confirmation before synchronizing external storages" which should already help for a lot of scenarios.
https://cloud.githubusercontent.com/assets/2644445/22258989/e928fa92-e263-11e6-9c70-575316035231.png
mmattel commentedon Feb 7, 2017
This is very good and useful !!
From the client side, clients (human) do not know and/or care if the storage behind is external or not, they just see "folders". And client side choices are, by design, not oC admin driven.
guruz commentedon May 11, 2017
@PVince81
Would it be easier for all implementations to get a new flag inside the oc:permissions?
soft: Something like an "advisory soft don't sync"?
hard: We of course return a 403 for that file/folder. However I think there should also be a flag in permissions being returned so that the clients can avoid even doing those unsucessful network requests?
So two new permissions in
core/apps/dav/lib/Connector/Sabre/Node.php
Line 291 in f10d105
PVince81 commentedon May 11, 2017
New property or not doesn't affect server implementation that much. Not sure about clients...
moscicki commentedon May 11, 2017
Yes. I agree that there are two cases: soft and hard "do-not-sync". This will provide a general framework to fit most of the applications.
Soft is anything that is just advisory and may be overriden by the client settings.
One application for soft is just a global exclude list maintained by the server and it may be overriden by the local client settings.
However hard means that the server will return 403 (or equivalent) when the client tries to access the subfolder. Therefore it does not make any sense for the client to try (or retry) to access this.
It makes sense to have this as a webdav property to avoid calls which we know will return 403. The client side logic could be the following:
You may take into account that this property may be modified in the future. So you should not cache forever (if at all) the value of this property on the client side.
If a request fails with 403 then one should see the property of enclosing parent folders. You can imagine that X/Y/Z fails with 403 but also X/Y fails with 403 because X is hard-do-not-sync. This can happen in the middle of the sync run if server property is modified but the subsequent sync run should handle it well.
My particular use-case for this is hard: a part of the tree is not readible by the current user.
ownclouders commentedon Dec 21, 2017
Hey, this issue has been closed because the label
status/STALEis 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.