[EOS] Downloading user shared files not possible using the owncloud storage driver

[C0rby]

With these changes cs3org/reva#929 accepting and listing shared files and folder is possible but downloading them returns an error.

The owncloud storage driver and possibly some parts of the reva storageprovider need to be changed to allow downloading the shared files. One big stepping stone IMO is this cs3org/reva#929 (comment). If that is not changed then there is no possibility to share files in a users home directory.
But also downloading files in shared folders doesn't work currently.

[PVince81]

Right, the challenge as in OC 10 is that those are likely "file based mount points" which is an odd concept.
I remember having to implement many special handling for that in the old OC. One example that comes to mind was quota handling, where the quota check needed to be done not on the folder it's mounted in, but in the original storage of the file, but also not directly on the file itself, but the parent folder on the original storage. A lot of gymnastics.

[labkode]

@C0rby can you elaborate a bit more on why downloading the files inside shared folder doesn't work? as far as I know you can perform metadata operations on them so data download should work in principle. Is is related with TUS? Did it work with the EOS driver?
Perhaps some log lines

[C0rby]

When use accepts a share we do the following (similar to eosfs):
Create a file in /var/tmp/reva/data/<user>/shadow_files/ with the same name of the shared file or folder. And add the reference to the original file in the extended attributes of the file.

To make that a bit less abstract here an example:

• einstein shares his folder /Physics/ with feynman.
• feynman accepts and wants to download /Physics/The_Theory_of_Relativity.pdf

What happens at some point is that GetMD in the owncloud storage driver is called with the path /var/tmp/reva/data/feynman/shadow_files/Shares/Physics/The_Theory_of_Relativity.pdf.
That path though doesn't exist since /var/tmp/reva/data/feynman/shadow_files/Shares/Physics is a file with an extended attribute pointing to the original folder.

The solution to this would be to detect paths to shared folders and resolve the original path before continuing with e.g. stating the file.

[labkode]

@C0rby the call to /var/tmp/reva/data/feynman/shadow_files/Shares/Physics/The_Theory_of_Relativity.pdf should not happen as the gateway intercepts this and calls only /var/tmp/reva/data/feynman/shadow_files/Shares/Physics/ to obtain the reference, this happens here: https://github.com/cs3org/reva/blob/master/internal/grpc/services/gateway/storageprovider.go#L150

Smells like either the gateway has a bug or your configuration is not correct.
How do you configure the share paths?

[C0rby]

Then this needs some more debugging.

Also I just tested listing a shared folder with the eos storage and got this error message:

gateway: error getting path for ref error="gateway: error stating ref:id:<storage_id:\"1284d238-aa92-42ce-bdc4-0b0000009154\" opaque_id:\"20\" > : rpc error: code = Internal desc = eos: resource is outside the directory of the logged-in user: internal=/eos/dockertest/reva/users/e/einstein/New folder trim=/eos/dockertest/reva/users/f/feynman namespace=/eos/dockertest/reva/users"

[PVince81]

upload and download as recipient with EOS works fine now.

but OC storage still has troubles, opened here owncloud/product#205