Getting content of a shared file with same name returns 500 #3880

SwikritiT · 2022-05-26T05:31:29Z

Describe the bug

Getting content of a shared file with same name returns 500

Steps to reproduce

Steps to reproduce the behavior:

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"
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"
As user marie and einstein share the file with user moss
As user moss create folder Shares
curl -X MKCOL -vk -u moss:vista https://localhost:9200/remote.php/dav/files/moss/Shares
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"
As moss accept both shares
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
<?xml version="1.0"?>
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/remote.php/dav/files/moss/Shares/</d:href>
    <d:propstat>
      <d:prop>
        <oc:id>a0ca6a90-a365-4782-871e-d44447bbc668!a0ca6a90-a365-4782-871e-d44447bbc668</oc:id>
        <oc:fileid>a0ca6a90-a365-4782-871e-d44447bbc668!a0ca6a90-a365-4782-871e-d44447bbc668</oc:fileid>
        <oc:spaceid>a0ca6a90-a365-4782-871e-d44447bbc668</oc:spaceid>
        <d:getetag>"c7169599f4f1362583d435ce9670192a"</d:getetag>
        <oc:permissions>S</oc:permissions>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:size>21</oc:size>
        <d:getlastmodified>Thu, 26 May 2022 04:12:53 GMT</d:getlastmodified>
        <oc:favorite>0</oc:favorite>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/moss/Shares/testfile.txt</d:href>
    <d:propstat>
      <d:prop>
        <oc:id>a0ca6a90-a365-4782-871e-d44447bbc668!9c4b291e-318e-4519-99d0-d3ff6ae8eaa7</oc:id>
        <oc:fileid>a0ca6a90-a365-4782-871e-d44447bbc668!9c4b291e-318e-4519-99d0-d3ff6ae8eaa7</oc:fileid>
        <oc:spaceid>a0ca6a90-a365-4782-871e-d44447bbc668</oc:spaceid>
        <d:getetag>"b27b29ab84624a51fea540f09e0ab572"</d:getetag>
        <oc:permissions>S</oc:permissions>
        <d:resourcetype/>
        <d:getcontentlength>10</d:getcontentlength>
        <d:getcontenttype>text/plain</d:getcontenttype>
        <d:getlastmodified>Thu, 26 May 2022 04:12:13 GMT</d:getlastmodified>
        <oc:checksums>
          <oc:checksum>SHA1:c9be619500b84cdc8391b9f00c3c532e2e5e0d33 MD5:79ffed91dea0b50d7b7fd966672b0d5e ADLER32:15d403e9</oc:checksum>
        </oc:checksums>
        <oc:favorite>0</oc:favorite>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/moss/Shares/testfile.txt</d:href>
    <d:propstat>
      <d:prop>
        <oc:id>a0ca6a90-a365-4782-871e-d44447bbc668!b77955be-6997-42ca-ba48-5d8c68bb67ed</oc:id>
        <oc:fileid>a0ca6a90-a365-4782-871e-d44447bbc668!b77955be-6997-42ca-ba48-5d8c68bb67ed</oc:fileid>
        <oc:spaceid>a0ca6a90-a365-4782-871e-d44447bbc668</oc:spaceid>
        <d:getetag>"c7169599f4f1362583d435ce9670192a"</d:getetag>
        <oc:permissions>S</oc:permissions>
        <d:resourcetype/>
        <d:getcontentlength>11</d:getcontentlength>
        <d:getcontenttype>text/plain</d:getcontenttype>
        <d:getlastmodified>Thu, 26 May 2022 04:12:53 GMT</d:getlastmodified>
        <oc:checksums>
          <oc:checksum>SHA1:13cab0433629cfe5307f0a71ee097f78fe671474 MD5:c855014a7bcf8d02b795b7eb0ef7cc0a ADLER32:19eb043d</oc:checksum>
        </oc:checksums>
        <oc:favorite>0</oc:favorite>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/moss/Shares/testfile.txt</d:href>
    <d:propstat>
      <d:prop>
        <oc:id>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!0ed44429-93ca-43e4-b449-43385bff2622</oc:id>
        <oc:fileid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!0ed44429-93ca-43e4-b449-43385bff2622</oc:fileid>
        <oc:spaceid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51</oc:spaceid>
        <d:getetag>"c7169599f4f1362583d435ce9670192a"</d:getetag>
        <oc:permissions>S</oc:permissions>
        <d:resourcetype/>
        <d:getcontentlength>21</d:getcontentlength>
        <d:getcontenttype>text/plain</d:getcontenttype>
        <d:getlastmodified>Thu, 26 May 2022 04:12:53 GMT</d:getlastmodified>
        <oc:checksums>
          <oc:checksum>SHA1:c9be619500b84cdc8391b9f00c3c532e2e5e0d33 MD5:79ffed91dea0b50d7b7fd966672b0d5e ADLER32:15d403e9</oc:checksum>
        </oc:checksums>
        <oc:favorite>0</oc:favorite>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

Setup

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

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.

The text was updated successfully, but these errors were encountered:

phil-davis · 2022-05-26T06:32:09Z

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 · 2022-06-01T12:55:17Z

partial fix in #3853

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

C0rby · 2022-06-07T14:46:59Z

@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 · 2022-06-21T11:27:26Z

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 · 2022-06-21T11:29:57Z

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 · 2022-06-22T10:29:24Z

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 · 2022-06-22T10:31:35Z

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

C0rby · 2022-06-22T13:16:14Z

@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 · 2022-06-22T13:33:48Z

hmm, this is a real drawback.

phil-davis · 2022-06-22T13:52:43Z

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 · 2022-07-27T04:16:37Z

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 · 2022-07-27T05:39:24Z

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

kiranparajuli589 · 2022-07-27T07:27:55Z

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 · 2022-07-27T09:13:24Z

reported here at #4289

Signed-off-by: Kiran Parajuli <[email protected]>

…ures-list [tests-only] removed closed issue #3880 from expected failures list

Merge: fd58035 3e5726b Author: PKiran <[email protected]> Date: Wed Jul 27 16:31:42 2022 +0545 Merge pull request #4290 from owncloud/remove-3880-from-expected-failures-list [tests-only] removed closed issue #3880 from expected failures list

SwikritiT added the Type:Bug label May 26, 2022

micbar self-assigned this May 30, 2022

butonic mentioned this issue Jun 1, 2022

correct share jail child aggregation cs3org/reva#2907

Merged

micbar closed this as completed Jun 14, 2022

phil-davis mentioned this issue Jun 20, 2022

State of OCM in reva cs3org/reva#2942

Closed

SagarGi mentioned this issue Jul 25, 2022

check current expected to fail files for closed issues owncloud/QA#716

Closed

8 tasks

kiranparajuli589 added a commit that referenced this issue Jul 27, 2022

Remove closed issue #3880 from the list of expected failures

ac1e7f7

Signed-off-by: Kiran Parajuli <[email protected]>

kiranparajuli589 mentioned this issue Jul 27, 2022

[tests-only] removed closed issue #3880 from expected failures list #4290

Merged

5 tasks

kiranparajuli589 added a commit that referenced this issue Jul 27, 2022

Remove closed issue #3880 from the list of expected failures

bd14595

Signed-off-by: Kiran Parajuli <[email protected]>

kiranparajuli589 added a commit that referenced this issue Jul 27, 2022

Remove closed issue #3880 from the list of expected failures

3e5726b

Signed-off-by: Kiran Parajuli <[email protected]>

kiranparajuli589 added a commit that referenced this issue Jul 27, 2022

Merge pull request #4290 from owncloud/remove-3880-from-expected-fail…

c2cb052

…ures-list [tests-only] removed closed issue #3880 from expected failures list

micbar moved this to Done in Infinite Scale Team Board Dec 16, 2022

micbar added this to Infinite Scale Team Board Dec 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Getting content of a shared file with same name returns 500 #3880

Getting content of a shared file with same name returns 500 #3880

SwikritiT commented May 26, 2022 •

edited

Loading

phil-davis commented May 26, 2022 •

edited

Loading

micbar commented Jun 1, 2022

C0rby commented Jun 7, 2022

phil-davis commented Jun 21, 2022

phil-davis commented Jun 21, 2022

C0rby commented Jun 22, 2022

C0rby commented Jun 22, 2022

C0rby commented Jun 22, 2022

micbar commented Jun 22, 2022

phil-davis commented Jun 22, 2022

kiranparajuli589 commented Jul 27, 2022 •

edited

Loading

phil-davis commented Jul 27, 2022

kiranparajuli589 commented Jul 27, 2022

kiranparajuli589 commented Jul 27, 2022

Getting content of a shared file with same name returns 500 #3880

Getting content of a shared file with same name returns 500 #3880

Comments

SwikritiT commented May 26, 2022 • edited Loading

Describe the bug

Steps to reproduce

Expected behavior

Actual behavior

Setup

Additional context

phil-davis commented May 26, 2022 • edited Loading

micbar commented Jun 1, 2022

C0rby commented Jun 7, 2022

phil-davis commented Jun 21, 2022

phil-davis commented Jun 21, 2022

C0rby commented Jun 22, 2022

C0rby commented Jun 22, 2022

C0rby commented Jun 22, 2022

micbar commented Jun 22, 2022

phil-davis commented Jun 22, 2022

kiranparajuli589 commented Jul 27, 2022 • edited Loading

phil-davis commented Jul 27, 2022

kiranparajuli589 commented Jul 27, 2022

kiranparajuli589 commented Jul 27, 2022

SwikritiT commented May 26, 2022 •

edited

Loading

phil-davis commented May 26, 2022 •

edited

Loading

kiranparajuli589 commented Jul 27, 2022 •

edited

Loading