Prevent deleted count from being wrongly decremented
* This could happen if a refresh() happens before an undo(); the
result could easily be crashes or other bad behavior, as
sDeletedCount drops below zero
* I suspect this will fix a number of bugs, but let's let it soak
a bit, perhaps, before considering them closed
Bug: 6249265
Change-Id: I37c612ceb4d22fc57f1daa96aab316ff8405bef6
diff --git a/src/com/android/mail/browse/ConversationCursor.java b/src/com/android/mail/browse/ConversationCursor.java
index bf6d885..c96adbe 100644
--- a/src/com/android/mail/browse/ConversationCursor.java
+++ b/src/com/android/mail/browse/ConversationCursor.java
@@ -349,12 +349,15 @@
// If we're in a requery and we're still around, remove the requery key
// We're good here, the cached change (delete/update) is on its way to UP
values.remove(REQUERY_COLUMN);
+ LogUtils.i(TAG, new Error(),
+ "IN resetCursor, remove requery column from %s", entry.getKey());
} else {
// Keep the deleted count up-to-date; remove the cache entry
if (values.containsKey(DELETED_COLUMN)) {
sDeletedCount--;
LogUtils.i(TAG, new Error(),
- "IN resetCursor, sDeletedCount decremented to: %d", sDeletedCount);
+ "IN resetCursor, sDeletedCount decremented to: %d by %s",
+ sDeletedCount, entry.getKey());
}
// Remove the entry
iter.remove();
@@ -481,6 +484,13 @@
sDeletedCount);
}
return;
+ } else if (!state) {
+ // Trying to undelete, but it's not deleted; just return
+ if (DEBUG) {
+ LogUtils.i(TAG, "Undeleted %s, IGNORING, deleted count=%d", uriString,
+ sDeletedCount);
+ }
+ return;
}
}
// ContentValues has no generic "put", so we must test. For now, the only classes