Different `PROPFIND` calls return different remoteId for the same file in Shares space

[JuancaG05]

Describe the bug

I have an oCIS account with a folder (/test) shared with me, so that it appears in my Shares space.

When I perform a PROPFIND to the root folder (/) of the Shares space, the remoteId of the /test folder following the response, is:

<oc:id>
a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!e908ab2e-2b75-49ee-9e75-9b3351131315:4c510ada-c86b-4815-8820-42cdf82c3d51:cde3f261-336c-4c8d-b5ad-0983c370737d
</oc:id>

When I perform a PROPFIND to the /test folder, the remoteId of the /test folder following the response, is:

<oc:id>
e908ab2e-2b75-49ee-9e75-9b3351131315$4c510ada-c86b-4815-8820-42cdf82c3d51!5ff70081-7096-4111-9570- d32077426178
</oc:id>

Two different IDs for the same folder!

Steps to reproduce

1. PROPFIND request to the root folder in Shares space
2. PROPFIND request to the child folder of the root folder in Shares space
3. Compare the IDs in the response

PROPFIND to the root folder (need to replace XXXX by a valid token):

curl -k -H 'Authorization: Bearer XXXX' -H 'Host: https://ocis.ocis-traefik.latest.owncloud.works' https://ocis.ocis-traefik.latest.owncloud.works/f/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668 -X PROPFIND

PROPFIND to the/test folder (need to replace XXXX by a valid token):

curl -k -H 'Authorization: Bearer XXXX' -H 'Host: https://ocis.ocis-traefik.latest.owncloud.works' https://ocis.ocis-traefik.latest.owncloud.works/f/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/test -X PROPFIND

Expected behavior

Same ID for the same folder in both PROPFIND responses to keep consistency.

Actual behavior

Different ID for the same folder depending on the PROPFIND performed.

Setup

I'm using ocis-traefik.latest, redirected from https://ocis.owncloud.works:

ownCloud Web UI 8.0.0-rc.3
Infinite Scale 5.1.0-prealpha+0d5437a00 Community

[butonic]

AFAICT this is might be caused by the server returnig multiple entries with the same href in random order when a file has been received in with multiple shares. Tracked in #8080

[rhafer]

AFAICT this is might be caused by the server returnig multiple entries with the same href in random order when a file has been received in with multiple shares.

No. This is unrelated.

The PROPFIND on the sharejail root returns the ids of the shared items inside the sharejail: <sharejailstorageid>$<sharejailspaceid>!<shareid>

The PROPFIND on of the items inside the sharejail returns the resourceIDs of the shared item.

Whether this is a bug. Or this is done on purpose I don't know yet.

[jesmrec]

any new here? i've tested with latest stuff

ownCloud Web UI 9.0.0-alpha.1 
Infinite Scale 5.1.0-prealpha+8e096ac58 Community 

id of a folder in the root of shares jail:

a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!15539cb1-e2cf-46f1-913e-989d93fcbf20:f6a14e29-826d-45dd-b574-195866854df2:a71da556-c089-408e-9761-3bc8e9491df4

id of the same folder but browsing inside (PROPFIND to its content)

15539cb1-e2cf-46f1-913e-989d93fcbf20$f6a14e29-826d-45dd-b574-195866854df2!161e7288-19cf-4284-bc66-e9ee010911ec

well, it seems to be closer to the expected behaviour above but it's not the same yet.

This problem is blocking owncloud/android#4302

[rhafer]

any new here? i've tested with latest stuff

Unfortunately no. I don't think anybody is currently actively working on this. Though AFAIK the current behavior for the ids (which is implemented in the share-storageprovider) is the way it is because of some weird requirement of the WOPI service. But this needs more investigation.

@micbar Should this get some priority?