Skip to content

Conversation

@icewind1991
Copy link
Member

This backports the improved mount conflict resolution logic from #57295 but keeps it at mount-time.

The old logic way of checking for conflict was causing a recursive filesystem setup which lead to false positives in the conflict detection.

Fixes #57748

@icewind1991 icewind1991 added this to the Nextcloud 33 milestone Jan 26, 2026
@icewind1991 icewind1991 requested a review from a team as a code owner January 26, 2026 14:42
@icewind1991 icewind1991 added the 3. to review Waiting for reviews label Jan 26, 2026
@icewind1991 icewind1991 requested review from artonge, leftybournes, nfebe and salmart-dev and removed request for a team January 26, 2026 14:42
@github-actions github-actions bot changed the title fix: improve share mount conflict resolution logic [stable33] fix: improve share mount conflict resolution logic Jan 26, 2026
@icewind1991 icewind1991 force-pushed the share-mount-validation-fixes-33 branch 5 times, most recently from 577c711 to b92f1c1 Compare January 26, 2026 15:46
@icewind1991 icewind1991 force-pushed the share-mount-validation-fixes-33 branch from b92f1c1 to 7de1833 Compare January 26, 2026 17:38
$validShareCache = $this->cacheFactory->createLocal('share-valid-mountpoint-max');
$maxValidatedShare = $validShareCache->get($userId) ?? 0;
$newMaxValidatedShare = $maxValidatedShare;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this valid share cache based on an id offset is dangerous and can lead to race conditions.

If 2 request concurrently add shares, one may have ids 1 and 3, and validate both, and the other one 1 and 2, and will skip validation of 2 because the last validated share id is 3.

I would feel a lot better if this cache was a map of validated shares. Maybe that’s not possible for performance reasons but then we need another solution, this is too fragile.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there is a case where getting the shares will return 3 but not 2? with auto-increment that isn't inside a transaction.

Storing the map of validated shares put to much of a load on the cache.

The logic has been working (as far as I know) fine since 32, this just moves it around a bit.

@icewind1991 icewind1991 force-pushed the share-mount-validation-fixes-33 branch from 7de1833 to 7fa5ada Compare January 27, 2026 15:35
@icewind1991
Copy link
Member Author

Also added a backport of 43a9335 to stop some false positives

Signed-off-by: Robin Appelman <robin@icewind.nl>
Signed-off-by: Robin Appelman <robin@icewind.nl>
…e positives

Signed-off-by: Robin Appelman <robin@icewind.nl>
Signed-off-by: Robin Appelman <robin@icewind.nl>
@icewind1991 icewind1991 force-pushed the share-mount-validation-fixes-33 branch from 7fa5ada to d0d38e4 Compare January 27, 2026 16:27
@icewind1991 icewind1991 marked this pull request as draft January 27, 2026 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3. to review Waiting for reviews

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants