mirror of
https://github.com/jberkel/sms-backup-plus.git
synced 2026-04-25 17:05:59 +03:00
[GH-ISSUE #529] undefined behaviour when new SMS received during restore #448
Labels
No labels
AM+RCS
FAQ
awaiting response
backup
bespoke
bug
calendar
call log
cannot reproduce
cloudless
device-specific
documentation
dual- & multi-SIM
duplicate
feature-request
fixed in beta
good first issue
half-missing
help wanted
helpful
meta
misattribution
mms
other message sources
pull-request
question
rejuvenation
restore
schedule
security
stale
task
thanks
v1.5.1
v1.5.10
v1.5.11
v1.5.2
v1.5.3
v1.5.3
v1.5.4
v1.5.4
v1.5.5
v1.5.5
v1.5.6
v1.5.7
v1.5.8
v1.5.9
v1.6β
xoauth
~$ bounty $~
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/sms-backup-plus-jberkel#448
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Lx on GitHub (Jan 26, 2015).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/529
The FAQ states that if SMS Backup+ is not deactivated as the default messaging app after a restore, new messages may be lost.
This suggests that any new messages received during a restore could be lost as well.
Explicit documentation of this would be greatly appreciated so that users can time restore operations to minimise the loss of new incoming messages.
Ideally, SMS Backup+ would just write these messages to the inbox and make a note to back them up during the next backup operation.
@jberkel commented on GitHub (Jan 26, 2015):
I haven't tried this myself but the best option for now would be to put the phone in airplane mode during restore. however you're right, it might be possible to just store the incoming message (similar to the way restore works)
@jberkel commented on GitHub (Mar 28, 2018):
Has been addressed in #809