You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: app/src/androidTest/java/org/thoughtcrime/securesms/messages/SyncMessageProcessorTest_synchronizeDeleteForMe.kt
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -706,6 +706,7 @@ class SyncMessageProcessorTest_synchronizeDeleteForMe {
Copy file name to clipboardExpand all lines: app/src/main/java/org/thoughtcrime/securesms/components/settings/app/internal/backup/InternalBackupPlaygroundViewModel.kt
* When we find out about a new inbound attachment pointer, we insert a row for it that contains all the info we need to download it via [insertAttachmentWithData].
941
925
* Later, we download the data for that pointer. Call this method once you have the data to associate it with the attachment. At this point, it is assumed
942
926
* that the content of the attachment will never change.
927
+
*
928
+
* @return True if we had to change the digest as part of saving the file, otherwise false.
Log.i(TAG, "[finalizeAttachmentAfterDownload] Finalizing downloaded data for $attachmentId. (MessageId: $mmsId, $attachmentId)")
947
933
948
934
val existingPlaceholder:DatabaseAttachment= getAttachment(attachmentId) ?:throwMmsException("No attachment found for id: $attachmentId")
@@ -969,6 +955,8 @@ class AttachmentTable(
969
955
cipherOutputStream.transmittedDigest
970
956
}
971
957
958
+
val digestChanged =!digest.contentEquals(existingPlaceholder.remoteDigest)
959
+
972
960
val foundDuplicate = writableDatabase.withinTransaction { db ->
973
961
// We can look and see if we have any exact matches on hash_ends and dedupe the file if we see one.
974
962
// We don't look at hash_start here because that could result in us matching on a file that got compressed down to something smaller, effectively lowering
* The first is the backfill process, which will happen after newly-enabling backups. That process will go:
2515
2507
* 1. [NONE]
2516
-
* 2. [BACKFILL_UPLOAD_IN_PROGRESS]
2517
-
* 3. [BACKFILL_UPLOADED]
2508
+
* 2. [UPLOAD_IN_PROGRESS]
2509
+
* 3. [COPY_PENDING]
2518
2510
* 4. [FINISHED] or [PERMANENT_FAILURE]
2519
2511
*
2520
2512
* The second is when newly sending/receiving an attachment after enabling backups. That process will go:
2521
2513
* 1. [NONE]
2522
-
* 2. [ATTACHMENT_TRANSFER_PENDING]
2514
+
* 2. [COPY_PENDING]
2523
2515
* 3. [FINISHED] or [PERMANENT_FAILURE]
2524
2516
*/
2525
2517
enumclassArchiveTransferState(valvalue:Int) {
2526
2518
/** Not backed up at all. */
2527
2519
NONE(0),
2528
2520
2529
2521
/** The upload to the attachment service is in progress. */
2530
-
BACKFILL_UPLOAD_IN_PROGRESS(1),
2522
+
UPLOAD_IN_PROGRESS(1),
2531
2523
2532
-
/** Successfully uploaded to the attachment service during the backfill process. Still need to tell the service to move the file over to the archive service. */
2533
-
BACKFILL_UPLOADED(2),
2524
+
/** We sent/received this attachment after enabling backups, but still need to transfer the file to the archive service. */
2525
+
COPY_PENDING(2),
2534
2526
2535
2527
/** Completely finished backing up the attachment. */
2536
2528
FINISHED(3),
2537
2529
2538
2530
/** It is impossible to upload this attachment. */
2539
-
PERMANENT_FAILURE(4),
2540
-
2541
-
/** We sent/received this attachment after enabling backups, but still need to transfer the file to the archive service. */
0 commit comments