Shares jail are available after disabling/deleting space

[ScharfViktor]

Infinite Scale 3.0.0-rc.1 Community
ownCloud Web UI 7.0.0-rc.32

Steps:

• space admin creates project space
• add folder f1 with file to the space
• share folder f1 to einstein and create public link with role uploader
• einstein accepts folder
• public open link
• space admin disabled space or delete (same behavior)

Actual: as a user einstein I don't understand what happens. I haven't any message or notification. I see shared folder and I know that there were files that aren't there now

• folder Shares/f1 is exist for einstein but it's empty

• all actions are available but after clicking user gets 400 code

• user can decline share and cannot accept again

• for public link available with enabled drop files button

Expect:

[micbar]

Very good finding!

IMO this "works as designed" but we have a bad design.

@butonic FYI

[micbar]

@butonic @kobergj @aduffeck can we teach the share manager to not list shares for disabled spaces?

[butonic]

The CS3 share manager (actually the jsoncs3 share manager implementation) should be unaware of resource state. ListShares should be dumb, return all shares and point to the resource. It will filter out expired shares because that is his responsibility.

For whatever reason the GetShare() implementation does a stat request, which it IMO should not make ... it is the responsibility of the consumer to verify if the resource still exists.

When a resource / folder / space is deleted we need to walk the tree to delete all shared resources ... should be an async process, similar to indexing. deleting a space can easily delete all shares in that space, but deleting a folder has to be smarter to invalidate all shares in that folder 🤔

now ... for this issue the ocs share handler which is the consumer for the ListShares call will have to do the Stating ... hm ... maybe if one of the stat calls fails we can indicate that a space is disabled? or we would have to differentiate between space and node ... 🤔

In any case listing shares reuqires a stat anyway ... but why is that still visible ... Ahhhh, because the stat is cached ... but we no longer use tha gateway stat cache ...

[butonic]

AFAICT this was cause by the stat cache. It has been disabled since rc1 because invalidating entries in the stat cache was too expensive. We currently rely on the more efficient filemetadata cache. I cannot reproduce this on current master.

[micbar]

should be fixed in RC.2