-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix valid storages removed when cleaning remote storages #25331
Fix valid storages removed when cleaning remote storages #25331
Conversation
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
/backport to stable20 |
/backport to stable19 |
The remote URL of a share is always stored in the database with a trailing slash. However, when a cloud ID is generated trailing slashes are removed. The ID of a remote storage is generated from the cloud ID, but the "cleanup-remote-storage" command directly used the remote URL stored in the database. Due to this, even if the remote storage was valid, its ID did not match the ID of the remote share generated by the command and ended being removed. Now the command generates the ID of remote shares using the cloud ID instead, just like done by the remote storage, so there is no longer a mismatch. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
91ff735
to
9ccabff
Compare
/backport to stable21 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code makes sense 👍
so after just merging this, psalm is unhappy about the merge: https://github.com/nextcloud/server/actions/runs/664180405 |
seems not, probably a hiccup from Github. |
The remote URL of a share is always stored in the database with a trailing slash. However, when a cloud ID is generated trailing slashes are removed.
The ID of a remote storage is generated from the cloud ID, but the
cleanup-remote-storage
command directly used the remote URL stored in the database. Due to this, even if the remote storage was valid, its ID did not match the ID of the remote share generated by the command and ended being removed.Now the command generates the ID of remote shares using the cloud ID instead, just like done by the remote storage, so there is no longer a mismatch.