Repository navigation
Conversation
A local file backup recorded "last backup" before copying attachments. If one attachment's file was missing, the copy threw on every run: old backups were never pruned, a new backup directory piled up each night, and the UI still reported a fresh backup. Skip and count attachments whose source can't be read, instead of aborting. Failures writing to the backup location still abort. Record the last backup details only after attachments are copied and old backups cleaned up. The resumption point now carries the backup date and size so a resumed job can record them when it finishes.
Contributor
|
This merged internally as 778f0e7, which will be available with an upcoming release! Thanks for the contribution. |
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.
Contributor checklist
Administrative:
Commits and testing:
Description
This fixes local file backups failing every night because of one unreadable attachment, while the UI still shows a fresh backup.
LocalFileBackupExportJobrecorded the last backup details before copying attachments. If one attachment's source file was missing,writeQueuedAttachmentsToDiskthrew, and since that attachment's export record was never deleted, every later run failed the same way. Old backups were never pruned, a new backup directory piled up each night, and the settings screen kept reporting a recent backup.This change:
.postBackupFileCopyresumption point, so a resumed job can record them when it finishes. A job that is mid-resume when this ships has a checkpoint without these keys and starts over once.Testing: I added
LocalFileBackupManagerTests.testCopyAttachmentsToDiskSkipsMissingFile, which deletes one queued attachment's file and checks that the copy doesn't throw, the other attachment is written and the export queue is drained. I also updatedLocalFileBackupExportJobRunnerTests.localFileBackup_resumedAfterCopyfor the new resumption point fields. To check for regressions, I ran all ofLocalFileBackupManagerTestsandLocalFileBackupExportJobRunnerTests(15 tests), and they pass. I did not run the full test suite.