Repository navigation
Conversation
kilrau
marked this pull request as ready for review
November 8, 2026 11:01
…and copy Content written through the documents provider is uploaded asynchronously after the file descriptor is closed, and the queued upload is bound to the remote path at that moment. A rename, move or copy issued right after the write ran on the server against the empty placeholder created by createDocument, and the upload was left pointing at a path that no longer existed. Apps that write to a temporary name and rename it when done (e.g. Signal's local backups) ended up with 0 byte files on the server. - Track every write in openForWrite before the file descriptor is handed out, as OPEN and then CLOSED_UPLOAD_NOT_QUEUED once the close is reported. The mark ends when the upload job is enqueued: startFilesUploadJob now returns its Job, which completes once WorkManager accepted the chain or enqueueing failed. - Rename, move and copy wait while a write is CLOSED_UPLOAD_NOT_QUEUED or the scheduled upload job still has to process the document: its upload row is in progress, or failed with a result the job retries. Rows are matched by account and exact path. An OPEN write is waited for only for a short grace period, since the close is reported asynchronously; a document that stays open is not blocked on. - The wait gives up only when no upload bytes of the account have been transferred for 10 minutes, so uploads that take hours are not cut short. Refs nextcloud#7846 Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Kilian <19181985+kilrau@users.noreply.github.com>
… moved or copied folders Renaming, moving or copying a folder right after writing a file inside it has the same problem as doing it to the file itself: the server-side operation runs against the empty placeholder and the queued upload targets the old path. Signal's current local backups write each snapshot into a signal-backup-<timestamp>-tmp folder and rename the folder when done, so they still end up with 0 byte files without this. Wait for writes and unfinished uploads of every file below the folder as well, matched by account and remote path prefix. Refs nextcloud#7846 Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Kilian <19181985+kilrau@users.noreply.github.com>
kilrau
force-pushed
the
fix/saf-rename-waits-for-pending-upload
branch
from
November 10, 2026 13:02
c5c8ba3 to
06c2a63
Compare
This branch has not been deployed
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.
Fixes #7846
Description
I encountered the pain of Signal's local backup to a Nextcloud folder leaving me with 0-byte files and Nextcloud in a retry loop until my phone battery was drained. Very frustrating situation as it takes a while to realize what's happening and search for a workaround (let Signal write to local Android folder and add this folder manually to Nextcloud Auto Upload) - see linked issue. As one can see from the issue as well, not only Signal but all apps that rename, move or copy right after writing a file are affected.
Out of scope: delete-after-write, read-after-write, an older write undoing a rename and potentially others
This is a first attempt to fix the underlying issue, split into two commits:
fix(document-provider): wait for pending uploads before rename, move and copy: before renaming, moving or copying a file, the provider waits until its upload has been queued and finished.fix(document-provider): also wait for pending uploads inside renamed, moved or copied folders: does the same for folders.Open questions for maintainers
renameDocument/moveDocument/copyDocument, with no overall limit, so that large uploads (several GB) on a slow connection still complete. It gives up only after 10 minutes without progress. Is blocking acceptable here, orwould you prefer an overall cap, or failing fast and leaving the retry to the calling app?
🖼️ Screenshots (Didn't take any)
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)