fix(quota): protect local files from deletion when quota blocked upload.#10001
Draft
fix(quota): protect local files from deletion when quota blocked upload.#10001
Conversation
1508fc1 to
6a96d3a
Compare
If a file failed to upload because the server quota was exceeded (HTTP 507), it was never actually stored on the server — but the sync client could still delete the local copy when the remote parent folder was later moved or deleted via the web interface. - checkNewDeleteConflict() now checks the error blacklist before issuing a local REMOVE. If the file carries an InsufficientRemoteStorage entry, it is kept locally and reported as a soft error instead. - The same _httpErrorCode = 507 is now also set in the discovery-phase quota check. Files that were previously synced are unaffected. Signed-off-by: Camila Ayres <hello@camilasan.com>
…letion. Two cases: - quota blocked file survives when its remote parent folder is deleted; already synced siblings are still removed. - regression: a plain new file with no quota error in a server deleted folder continues to be deleted as before. Signed-off-by: Camila Ayres <hello@camilasan.com>
6a96d3a to
cb01eb1
Compare
|
Artifact containing the AppImage: nextcloud-appimage-pr-10001.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
|
Member
Author
|
/backport to stable-33.0 |
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
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.




Resolves
When files fail to upload due to a storage quota error, they never reach the server and have no sync record. If the user then moves the affected folder from the web interface, the sync client sees the folder as deleted and removes the local copies - permanently losing data that was never backed up.
A second, quieter variant of the same problem exists when the server's PROPFIND response already reports zero available space: those files are rejected during discovery before any upload is attempted, so they also end up with no protective record and are equally at risk.
Fix: Before deleting a local file inside a remotely-deleted folder, the client now checks the error blacklist for an InsufficientRemoteStorage entry. If one is found, the file is kept locally and surfaced as an error instead of being silently removed. The parent folder is preserved too, so the file stays reachable until the user resolves the quota situation.
_httpErrorCode is set to 507 on both the protected item and on files rejected by the discovery phase quota check. This ensures blacklistUpdate writes - and keeps renewing - the InsufficientRemoteStorage entry, so protection holds across multiple sync cycles even after the initial backoff period expires.
Files that were previously synced successfully are unaffected.
TODO
Checklist
AI (if applicable)