fix(files_sharing): don't crash CleanupShareTarget when mount info is missing - #63495
Conversation
… missing The repair step "Cleanup share names with false conflicts" fatals with "Call to a member function getRootId() on null" when a problem share's old target has no entry in the recipient's cached mounts (e.g. the recipient has not logged in since the share was created). Guard the lookup the same way the generateUniqueTarget callback already does and skip the mount cache refresh in that case - the share row is already updated by moveShare() and the cache is rebuilt on the user's next login. Fixes nextcloud#63494 Signed-off-by: Baki Burak Öğün <63836730+bakiburakogun@users.noreply.github.com>
a07346d to
2149378
Compare
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Summary
occ maintenance:repair --include-expensiveaborts in the "Cleanup share names with false conflicts" step:This happens when a problem share's old target has no entry in the recipient's cached mounts — in our case recipients who had not logged in since the share was created, so
oc_mountshad no row for those targets. The array lookup at line 122 yieldsnulland thegetRootId()call throws; since it is anError, thecatch (\Exception)below doesn't catch it and the whole repair run dies.Guard the lookup with
?? null— the same way thegenerateUniqueTarget()callback a few lines above already does — and skip the mount-cache refresh for that share. The share row itself is already updated bymoveShare()at that point, and the mount cache rebuilds on the user's next login.Fixes #63494
How to test
file_targetcontains a duplicated conflict suffix (Folder (2) (2))oc_mountsrow for that target (e.g. a user who never logged in since the share was created)occ maintenance:repair --include-expensive— without this patch the run aborts at that share; with it the step completes (verified on 34.0.3 over 907 problem shares)Checklist