Getting content of a shared file with same name returns 500

[SwikritiT]

Describe the bug

Getting content of a shared file with same name returns 500

Steps to reproduce

Steps to reproduce the behavior:

1. As user marie create a file testfile.txt with content first file curl -X PUT -vk -u marie:radioactivity https://localhost:9200/remote.php/dav/files/marie/testfile.txt -d"first file"
2. As user einstein create a file testfile.txt with content second file curl -X PUT -vk -u einstein:relativity https://localhost:9200/remote.php/dav/files/marie/testfile.txt -d"second file"
3. As user marie and einstein share the file with user moss
4. As user moss create folder Shares curl -X MKCOL -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares
5. As moss create a file Shares/testfile.txt with content third file curl -X PUT -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares/testfile.txt -d"third file"
6. As moss accept both shares
7. Now as moss get the file curl -X GET -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares/testfile.txt

Expected behavior

There should be certain differentiation on which file to get , put and the request should work

Actual behavior

You should be able to get the content of the file but as there are 3 files now that could be Shares/testfile.txt there's no knowing in api level which file to get and the request fails with 500

curl -X GET -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares/testfile.txt

``` Note: Unnecessary use of -X or --request, GET is already inferred. * Trying 127.0.0.1:9200... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 9200 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: O=Acme Corp; CN=OCIS * start date: May 25 05:08:52 2022 GMT * expire date: May 25 05:08:52 2023 GMT * issuer: O=Acme Corp; CN=OCIS * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Server auth using Basic with user 'moss' > GET /remote.php/dav/files/moss/Shares/testfile.txt HTTP/1.1 > Host: localhost:9200 > Authorization: Basic bW9zczp2aXN0YQ== > User-Agent: curl/7.68.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * Mark bundle as not supporting multiuse < HTTP/1.1 500 Internal Server Error < Access-Control-Allow-Origin: * < Content-Length: 0 < Content-Security-Policy: default-src 'none'; < Date: Thu, 26 May 2022 04:19:16 GMT < X-Content-Type-Options: nosniff < X-Download-Options: noopen < X-Frame-Options: SAMEORIGIN < X-Permitted-Cross-Domain-Policies: none < X-Robots-Tag: none < X-Xss-Protection: 1; mode=block < * Connection #0 to host localhost left intact ```

Same behaviour for put request as well and probably other request too.

curl -X PUT -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares/testfile.txt -d"test file file"

``` * Trying 127.0.0.1:9200... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 9200 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: O=Acme Corp; CN=OCIS * start date: May 25 05:08:52 2022 GMT * expire date: May 25 05:08:52 2023 GMT * issuer: O=Acme Corp; CN=OCIS * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Server auth using Basic with user 'moss' > PUT /remote.php/dav/files/moss/Shares/testfile.txt HTTP/1.1 > Host: localhost:9200 > Authorization: Basic bW9zczp2aXN0YQ== > User-Agent: curl/7.68.0 > Accept: */* > Content-Length: 14 > Content-Type: application/x-www-form-urlencoded > * upload completely sent off: 14 out of 14 bytes * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * Mark bundle as not supporting multiuse < HTTP/1.1 500 Internal Server Error < Access-Control-Allow-Origin: * < Content-Length: 0 < Content-Security-Policy: default-src 'none'; < Date: Thu, 26 May 2022 05:27:43 GMT < X-Content-Type-Options: nosniff < X-Download-Options: noopen < X-Frame-Options: SAMEORIGIN < X-Permitted-Cross-Domain-Policies: none < X-Robots-Tag: none < X-Xss-Protection: 1; mode=block < * Connection #0 to host localhost left intact ```

The propfind to the Shares folder

curl -X PROPFIND -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares | xmllint --format -

``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1:9200... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 9200 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs } [5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * TLSv1.3 (IN), TLS handshake, Server hello (2): { [122 bytes data] * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): { [6 bytes data] * TLSv1.3 (IN), TLS handshake, Certificate (11): { [835 bytes data] * TLSv1.3 (IN), TLS handshake, CERT verify (15): { [264 bytes data] * TLSv1.3 (IN), TLS handshake, Finished (20): { [36 bytes data] * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] * TLSv1.3 (OUT), TLS handshake, Finished (20): } [36 bytes data] * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: O=Acme Corp; CN=OCIS * start date: May 25 05:08:52 2022 GMT * expire date: May 25 05:08:52 2023 GMT * issuer: O=Acme Corp; CN=OCIS * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Server auth using Basic with user 'moss' } [5 bytes data] > PROPFIND /remote.php/dav/files/moss/Shares HTTP/1.1 > Host: localhost:9200 > Authorization: Basic bW9zczp2aXN0YQ== > User-Agent: curl/7.68.0 > Accept: */* > { [5 bytes data] * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): { [130 bytes data] * Mark bundle as not supporting multiuse < HTTP/1.1 207 Multi-Status < Access-Control-Allow-Origin: * < Access-Control-Expose-Headers: Tus-Resumable, Tus-Version, Tus-Extension < Content-Security-Policy: default-src 'none'; < Content-Type: application/xml; charset=utf-8 < Date: Thu, 26 May 2022 04:20:31 GMT < Dav: 1, 3, extended-mkcol < Tus-Extension: creation,creation-with-upload,checksum,expiration < Tus-Resumable: 1.0.0 < Tus-Version: 1.0.0 < X-Content-Type-Options: nosniff < X-Download-Options: noopen < X-Frame-Options: SAMEORIGIN < X-Permitted-Cross-Domain-Policies: none < X-Robots-Tag: none < X-Xss-Protection: 1; mode=block < Transfer-Encoding: chunked < { [5 bytes data] 100 3539 0 3539 0 0 9749 0 --:--:-- --:--:-- --:--:-- 9749 * Connection #0 to host localhost left intact /remote.php/dav/files/moss/Shares/ a0ca6a90-a365-4782-871e-d44447bbc668!a0ca6a90-a365-4782-871e-d44447bbc668 a0ca6a90-a365-4782-871e-d44447bbc668!a0ca6a90-a365-4782-871e-d44447bbc668 a0ca6a90-a365-4782-871e-d44447bbc668 "c7169599f4f1362583d435ce9670192a" S 21 Thu, 26 May 2022 04:12:53 GMT 0 HTTP/1.1 200 OK /remote.php/dav/files/moss/Shares/testfile.txt a0ca6a90-a365-4782-871e-d44447bbc668!9c4b291e-318e-4519-99d0-d3ff6ae8eaa7 a0ca6a90-a365-4782-871e-d44447bbc668!9c4b291e-318e-4519-99d0-d3ff6ae8eaa7 a0ca6a90-a365-4782-871e-d44447bbc668 "b27b29ab84624a51fea540f09e0ab572" S 10 text/plain Thu, 26 May 2022 04:12:13 GMT SHA1:c9be619500b84cdc8391b9f00c3c532e2e5e0d33 MD5:79ffed91dea0b50d7b7fd966672b0d5e ADLER32:15d403e9 0 HTTP/1.1 200 OK /remote.php/dav/files/moss/Shares/testfile.txt a0ca6a90-a365-4782-871e-d44447bbc668!b77955be-6997-42ca-ba48-5d8c68bb67ed a0ca6a90-a365-4782-871e-d44447bbc668!b77955be-6997-42ca-ba48-5d8c68bb67ed a0ca6a90-a365-4782-871e-d44447bbc668 "c7169599f4f1362583d435ce9670192a" S 11 text/plain Thu, 26 May 2022 04:12:53 GMT SHA1:13cab0433629cfe5307f0a71ee097f78fe671474 MD5:c855014a7bcf8d02b795b7eb0ef7cc0a ADLER32:19eb043d 0 HTTP/1.1 200 OK /remote.php/dav/files/moss/Shares/testfile.txt 1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!0ed44429-93ca-43e4-b449-43385bff2622 1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!0ed44429-93ca-43e4-b449-43385bff2622 1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51 "c7169599f4f1362583d435ce9670192a" S 21 text/plain Thu, 26 May 2022 04:12:53 GMT SHA1:c9be619500b84cdc8391b9f00c3c532e2e5e0d33 MD5:79ffed91dea0b50d7b7fd966672b0d5e ADLER32:15d403e9 0 HTTP/1.1 200 OK ```

Setup

Please describe how you started the server and provide a list of relevant environment variables.

```console OCIS_VERSION=vX.X.X BRANCH=vX.X.X STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false ```

Additional context

Add any other context about the problem here.

[phil-davis]

All 3 resources are returned in the PROPFIND of Shares, that seems "a good thing" - they each have unique oc:id oc:fileid, so that makes them unique. But they all report the same href

<d:href>/remote.php/dav/files/moss/Shares/testfile.txt</d:href>

I guess there might be some way for a new client to know about this kind f thing, and display all 3 resources, and then fetch the content of a resource by specifying a path that uses the unique file id, in order to get the content of one of the resources. And the client could lookup the OCS Sharing API to try to sort out which resource is a share received from which user etc. So maybe there is a possible algorithm for new clients to implement a way to show an end-user a set of useful meta-data about the resource, and the user to be able to choose which resource(s) they want to access (view/download/update...)

But existing clients "in the wild" are going to use the href value, and try to access the resource using the remote.php path that uses a path of file/folder names. There are 3 resources with exactly the same path. Even if the current 500 HTTP status problem is fixed, there is still the problem of which resource content should be returned when a client requests /remote.php/dav/files/moss/Shares/testfile.txt - the server is going to find that the path matches 3 resources? How can it decide what to do?

[micbar]

partial fix in #3853

Creating a Shares folder inside the users home directory is still possible.

[C0rby]

@micbar, I think this issue can be closed. We don't offer a way to get a shared file via /webdav or /dav/files so there is no ambiguity about which file is requested.

Creating a Shares folder is working but it's also not forbidden since we have the new shares view, AFAIK.

[phil-davis]

The user can create a Shares folder. But after the user receives some incoming shares from other users, attempts to access the user's own folder called Shares using a path like /dav/files/alice/Shares always gives resources that are received shares.

The user's own Shares folder does still exist - the "web" app displays it. I guess that the web app explicitly looks in the Personal space of the user, using the space-id. Older clients that don't understand all this are going to display/sync the incoming shares correctly, and miss a "duplicate" folder called "Shares" (if the user created one). Probably not a big issue.

[phil-davis]

Received shares with matching names now get (n) after the name to make the names unique - I have managed to get Carol seeing shares of folders and files from Alice and Brian OK:

[C0rby]

The user can create a Shares folder. But after the user receives some incoming shares from other users, attempts to access the user's own folder called Shares using a path like /dav/files/alice/Shares always gives resources that are received shares.

You're right. Also a PROPFIND on /dav/files/alice shows both, the Shares folder and the Shares jail. Now since we seperated the views in the frontend and access the Shares jail via id, should the path of the jail still be shares or maybe something else?

[C0rby]

The Desktop client also behaves in strange ways because of this:

[C0rby]

@butonic @micbar, do we need to keep calling the shares jail Shares or could we use a different more unique name to avoid the situation above? It would not solve it completely though.

[micbar]

hmm, this is a real drawback.

[phil-davis]

It's always a nuisance/problem if a namespace is "polluted" by "special" things, or things that "just arrive" largely out of the user's control. This problem exists in oC10 - if share_folder is set to something, then the backend and frontend software has to make some effort to prevent users creating that folder themselves. And sync clients can't do anything about it, a user can create a folder called Shares on their laptop, then connect the folder above it to ownCloud and the desktop sync client has a problem to solve. If share_folder remains as / (the root) then received shares come directly into the user's file system and pollute the name-space for the user.

Maybe the /dav/files/$user endpoint should just respond with resources from the user's real own personal space. And some other /dav/shares/$user endpoint can respond with the names of the received shares. Then there is still the issue of what to do when multiple users share their own myFolder with me, and I have multiple myFolder "landing" in /dav/shares/$user - but some automated name-uniqueness algorithm can handle that, and give users the option to rename incoming received shares to whatever they would like to call them (that works in oC10).

[kiranparajuli589]

Update If two users share a resource with the same name as another user. Then in oC10, the duplication is managed by adding (2) at the end of the name of the resource. But with oCIS (1) is added for the first duplication.

Is this slight difference expected thing? @micbar @C0rby

[phil-davis]

@individual-it ^ - FYI this is what was mentioned this morning.

[kiranparajuli589]

Update If two users share a resource with the same name as another user. Then in oC10, the duplication is managed by adding (2) at the end of the name of the resource. But with oCIS (1) is added for the first duplication.

Is this slight difference expected thing? @micbar @C0rby

There are other problems with this too. I'll create a separate issue.

[kiranparajuli589]

reported here at https://github.com/owncloud/ocis/issues/4289