Hide Virtual root folder if displayed in userFolder

[skjnldsv]

Call summary

• Core needs a way to mark folders as hidden
• Create a readonly global hidden root folder
  • Allow apps to register their home folder
    
  • Automatically set as hidden the said home folder
  • Let apps manage content as usual via dav
• Drop the recipient feature of the virtualfolder and rely on sharing to share with another user/group

Old issue content (Click to expand)

Currently, we are facing a dilemma with those two options

1. We put the virtualfolder root in /dav/virtualfolder/USER
2. We create a root folder in the userFolder /dav/files/USER/Albums

With solution 1, sharing is unfortunately not possible.
With solution 2, sharing is, but the folders are exposed and create multiple issues

• Shown to the user where it should not
• Present in the sync requests and can create lot of storage issues on the client side

Options

So here comes the question, how can we hide the said virtualfolder's RootFolder in the userFolder.
Talk also faced that dilemma

• Dav property was suggested, but I don't think we could hide results that don't match from a propfind?
• Use .RootFolder syntax to fake a "hidden folder". Not very clean, can still appear in the clients, needs user setting
• ... ?

Goals

• We need to still be able to access said rootFolder, it should just not be shown in PROPFIND requests
• ...?

[artonge]

Quick thoughts with some probably wrong assumptions on how it all work:

2. We create a root folder in the userFolder /dav/files/USER/Albums

With solution 2 we also face the problem of creating a folder that the user will not see, which could override an existing folder, or prevent the user from creating a folder without him understanding why because the name would already be taken. So the virtual folder would need to have a random name or something and maybe be visible to the user to prevent magic errors.

• Use .RootFolder syntax to fake a "hidden folder". Not very clean, can still appear in the clients, needs user setting

I like this solution as it is canonical with existing systems. If we are also able to block folder listing for the virtual folder, this would mean that the user will be able to see the folder and access individual files, but he won't be able to list its content. So maybe less problem in clients?

I think creating a folder like .virtual_<user-specific-random-string> in the user's root folder is a nice solution. It would be easy to add a condition to not return it in PROPFIND requests. But if its content is not listable, it might not even be necessary.

[blizzz]

Dav property was suggested, but I don't think we could hide results that don't match from a propfind?

My memory on the dav methods is not overly clear anymore, but I would suspect that we may involve the check in this case. Our connector/plugin should run there anyway, so I think we can filter in that case. The question is if we really want to do it at this point, might be unexpected and the future us's could get grumpy?

But so far the best option, the .HiddenThing will not work well for the reasons pointed out. And will still sync.

@artonge has a good point in overwriting folders and the suggestion to use a random name. It could also be a fixed OID value. Luckily Nextcloud has an official OID (1.3.6.1.4.1.49213) and the underlying structure is ours. So far it is used for LDAP purposes only, but lets add 1.3.6.1.4.1.49213.2 for special directory names. Can be described, looked up and extended → have .1.3.6.1.4.1.49213.2.1 in root for a first name, yet i would still keep it in combination with the DAV property. Opinions?

[PVince81]

is it only about hiding from listing or is direct DAV access desired when knowing the name ?
do we need to prevent users to create a folder named like this if it doesn't exist yet ?

this part of the requirement is not clear

[icewind1991]

Hidden folder pr: nextcloud/server#29886