fix(files_sharing): don't abort share:list when orphaned shares exist - #62060
fix(files_sharing): don't abort share:list when orphaned shares exist#62060Fantu wants to merge 1 commit into
Conversation
`occ share:list` resolved the source node of every share without handling NotFoundException, so a single orphaned share (e.g. the source file was deleted from disk externally, or is pending removal by DeleteOrphanedSharesJob) aborted the whole command with "Node for share not found" and produced no output at all. Catch the exception in both places that resolve the share node: orphaned shares are now listed with a null source-path, and the --parent filter skips them instead of crashing. Add unit tests for the command (previously untested), covering listing with an orphaned share present and the --parent filter with and without --recursive. Closes nextcloud#61949 Assisted-by: ClaudeCode:claude-fable-5 Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
|
I have now also tested the fix on a small production server running Nextcloud 32.0.11 (patch applied manually to @icewind1991 thank you for adding the |
CarlSchwan
added
3. to review
|
/backport to stable33 |
|
/backport to stable34 |
|
@CarlSchwan thanks for the fast review, can you please also backports to nc 32? I already tested on it I'm already using on production server (nc 32) |
|
/backport to stable32 |
|
Some of the CI workflow are a bit flacky. I will restart them if needed, just don't rebase your PR :) |
|
thanks for the reply and backport to nc32 |
|
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.) |
2 participants
Summary
For several years I have been administering a server where 50–60 people work mainly with Nextcloud and Onlyoffice, and over the years they have created thousands of user shares.
When someone asked me to restore files from backup, in the cases involving shares between users they often could not tell me the exact origin of the shared file, and in two cases I wasted a lot of time because of that.
Since occ had no
share:listcommand at the time, I had written an external script that generated a similar list every day, so that during a restore I could quickly find the origin of a share by looking at that list in a backup from a day when the share still existed.Nextcloud 32 finally added
share:listto occ, but unfortunately on that server (and I suppose in many other cases) it was unusable: some orphaned shares are always present, and a single one is enough to make the whole command abort.I considered working around it by always deleting the orphaned shares first, but I don't want to lose the few cases where a restore can actually repair a share, nor risk needlessly removing shares because of temporary problems with the SMB file server or something else.
So I made this change so that the command also works when orphaned shares exist.
Note that orphaned shares are not skipped but included in the list, even though the most important piece of information (the source path) is missing and shown as empty/null. For cases like mine this still has some value: from the orphaned entries you can immediately tell whether a share with the exact name (or a similar one) mentioned by the user actually existed, and who it was shared with. This is already a small improvement over my old external script, which excluded orphaned shares, so I had to dig through several backups just to confirm that the share had existed at all and what it was called. I think keeping the orphaned entries visible where possible can be useful to others as well.
I also added unit tests to catch possible regressions; this command previously had no tests at all.
TODO
Checklist
3. to review, feature component)stable32)AI (if applicable)