allow storing multiple mounts for the same rootid in the mount cache#32877
Merged
icewind1991 merged 2 commits intomasterfrom May 2, 2023
Merged
allow storing multiple mounts for the same rootid in the mount cache#32877icewind1991 merged 2 commits intomasterfrom
icewind1991 merged 2 commits intomasterfrom
Conversation
Member
Author
|
Motivation for fixing this is the virtualfolder app which makes it easy to have the same rootid mounted multiple times |
come-nc
approved these changes
Jun 28, 2022
come-nc
requested changes
Jun 28, 2022
Contributor
come-nc
left a comment
There was a problem hiding this comment.
Actually the tests on files_sharing are failing with:
OCP\Share\Exceptions\GenericShareException: Could not get proper share mount for 1228. Failing since else the next calls are called with null
Contributor
|
The autoloaders are also not up to date. |
Member
|
@icewind1991 can you clean up the PR ? |
594a7ee to
f15414c
Compare
Merged
Merged
Merged
Merged
df47c4a to
05b40a3
Compare
05b40a3 to
5896bdb
Compare
Member
Author
|
switched adding the new index to "add missing indexes" instead of the db migration to prevent slow db migration. |
artonge
approved these changes
Apr 24, 2023
currently `[$userId, $rootId]` is used as the unique key for storing mounts in the mount cache, however there are cases where the same rootid is mounted in multiple places for a user which currently leads to not all of those mounts being added to the cache. Previously this didn't matter as the mount cache was only used to list users with access to a specific file, so a user having access to the file multiple times didn' change anything. With 24 the mount cache is used for more cases and multiple mounts for the same id becomes relevant. While I think there isn't a real negative effect atm besides missing the optimized path we should ensure that the mounts are properly listed Signed-off-by: Robin Appelman <[email protected]>
Signed-off-by: Robin Appelman <[email protected]>
5896bdb to
db43d90
Compare
Member
Author
|
/backport to stable26 |
Member
Author
|
/backport to stable25 |
Contributor
|
Does this fix #37473 ? |
Member
Author
|
I don't think so |
1 task
1 task
4 tasks
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
currently
[$userId, $rootId]is used as the unique key for storing mounts in the mount cache,however there are cases where the same rootid is mounted in multiple places for a user which currently leads to not all of those mounts being added to the cache.
Previously this didn't matter as the mount cache was only used to list users with access to a specific file, so a user having access to the file multiple times didn' change anything.
With 24 the mount cache is used for more cases and multiple mounts for the same id becomes relevant.
While I think there isn't a real negative effect atm besides missing the optimized path we should ensure that the mounts are properly listed
Signed-off-by: Robin Appelman [email protected]