ResourceInfo bug

[piotrWichlinskiSoftwaremind]

Working with shares I have encountered a problem when using two-server-config from Reva’s example configs when stating a shared file with resourceId / path I get two different opaque_id on the same file. So when sharing a file when I stat /home/untitled2.txt I get: storage_id: "123e4567-e89b-12d3-a456-426655440000" opaque_id: " fileid-einstein/untitled2.txt"

And when stating the same shared file but on path /reva/einstein/untitled2.txt I get a resource id looking like that: storage_id: "123e4567-e89b-12d3-a456-426655440000" opaque_id: "fileid-/einstein/untitled2.txt "

It looks like there is a small difference in opauqe_id between local and localhome dataprovider/storageprovider drivers

[gmgigi96]

I think that the problem here is the config that is wrong. The two storage providers, one mounted in /home and the other in /reva, share the same mount_id. But this is wrong, as that parameter should be unique between all the storage drivers. The fact that the opaque_ids differ is totally fine, even if they are pointing to the same underlying file. In fact the routing of a Stat done by a ResourceId done in the StorageRegistry is based on the storage_id. Than is responsibility of the correct storage driver to understand which is the correct resource from the opaque_id, based on the type of the driver + config. I will create a PR to fix this example.

[butonic]

IIRC master uses the home provider as a jail for the users home. The resources are in fact identical and as such should have the same resource id. when routing via id requests should use the storage provider at /reva. The /home provider just provides an alternative path. The original config by @labkode was also using the same storageid for both ...

on edge things are different because ocdav translates the /webdav endpoint into the users home if desired. /home on the cs3 api is unnecessary because gethome will give you the correct storage provider. ...

with regards to shares and resource ids: shares are tied to resource ids, because they don't change when a resource is renamed, but they obviously have to be unique. the spaces concept on the edge branch has that solved because it no longer needs a home jail.

The challenge for shares arises when trying to construct a path that the share recipient can use to access the shared resource. the sharestorageprovider allows mounting a /Myshares folder, for example in the users homes that lists all the accepted shares a user has access to. It uses the resourceid to forward requests to the correct storageprovider.

for sharing being able to share the exact same resource twice: once via a user home and once via a storage provider at /reva can only be confusing to end users. That is the reason why they should have the same mount id.