-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Deleting one message causes another arbitrary message to be deleted #148
Comments
Commit 44c540b (Fixed updating last message after deleting (FossifyOrg#167), 2021-09-04) introduced a hack to update the conversation snippet, however there is a bug in that code: it tries to delete by thread ID, but the condition is applied to the SMS table, not to the threads table.[1] So instead of deleting the thread with that ID, it deletes whichever SMS happens to have that ID. The fix is to change the condition to an always-false condition, so that no messages will be deleted. The threads will still get updated.[2] Fixes FossifyOrg#148. [1] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1405 [2] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1409
Commit 44c540b (Fixed updating last message after deleting (FossifyOrg#167), 2021-09-04) introduced a hack to update the conversation snippet, however there is a bug in that code: it tries to delete by thread ID, but the condition is applied to the SMS table, not to the threads table.[1] So instead of deleting the thread with that ID, it deletes whichever SMS happens to have that ID. The fix is to change the condition to an always-false condition, so that no messages will be deleted. The threads will still get updated.[2] Fixes FossifyOrg#148. [1] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1405 [2] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1409
Commit 44c540b (Fixed updating last message after deleting (FossifyOrg#167), 2021-09-04) introduced a hack to update the conversation snippet, however there is a bug in that code: it tries to delete by thread ID, but the condition is applied to the SMS table, not to the threads table.[1] So instead of deleting the thread with that ID, it deletes whichever SMS happens to have that ID. The fix is to change the condition to an always-false condition, so that no messages will be deleted. The threads will still get updated.[2] Fixes FossifyOrg#148. [1] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1405 [2] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1409
It might be possible to recover unintentionally-deleted messages using the Room DAO cache, I'm not sure how easy/reliable that would be. Either way, I think my proposed fix (#149) should be merged and released ASAP (I don't think it will interfere with potential future recovery efforts). |
@Aga-C have you tried reproducing this bug? |
@naveensingh I was able to reproduce it after the fresh install of the app with no SMS messages on the phone yet. With more messages, maybe either I didn't notice or the IDs were already so high that nothing got removed. I've also checked, no one reported it in Simple SMS Messenger, but the code has been there since 2021. |
For reference, when there are many messages, the behaviour I'm predicting is that if you delete a message from a conversation whose ID is i (meaning, the i-th oldest conversation by date of first message), then it will also delete the message with ID i (meaning the i-th oldest message across all conversations). So it will be the oldest messages that get unintentionally deleted, and the unintentional deletion will only occur for the first deletion in each conversation. To maximise the chances of discovery, the process would be:
Obviously back up the messages first. Personally I wouldn't attempt this on a device with important messages, even with a backup. (Edited to clarify) |
Commit 44c540b (Fixed updating last message after deleting (FossifyOrg#167), 2021-09-04) introduced a hack to update the conversation snippet, however there is a bug in that code: it tries to delete by thread ID, but the condition is applied to the SMS table, not to the threads table.[1] So instead of deleting the thread with that ID, it deletes whichever SMS happens to have that ID. The fix is to change the condition to an always-false condition, so that no messages will be deleted. The threads will still get updated.[2] Fixes FossifyOrg#148. [1] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1405 [2] https://android.googlesource.com/platform/packages/providers/TelephonyProvider/+/android14-release/src/com/android/providers/telephony/MmsSmsProvider.java#1409
Proposed fix: #149.
Checklist
Affected app version
1.0.1
Affected Android/Custom ROM version
Android 14
Affected device model
Emulator
How did you install the app?
GitHub releases
Steps to reproduce the bug
(See screen recording for demo)
Expected behavior
There should still be two SMS's there ("Message 1" and "Message 2").
Actual behavior
"Message 2" is deleted (!)
Screenshots/Screen recordings
screenrecord.mp4
(the end got clipped a little, you may need to pause to see that Message 2 disappears)
Additional information
Workaround: DO NOT DELETE MESSAGES
Cause: Commit 44c540b introduced a hack to update the conversation snippet, however there is a bug in that code: it tries to delete by thread ID, but the condition is applied to the SMS table, not to the threads table (Android source).
So instead of deleting the thread with that ID, it deletes whichever SMS happens to have that ID.
Proposed solution:
I haven't tested this yet, butI believe changing the condition to "1=0" will fix the issue (it will still cause the threads to be updated but won't delete anything). Update: I've tested it using the steps above and it seems to work fine, but additional testing would be welcome.CC: @Aga-C
The text was updated successfully, but these errors were encountered: