summaryrefslogtreecommitdiffstats
path: root/sync/syncable/dir_open_result.h
diff options
context:
space:
mode:
authorrlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-05-16 19:09:47 +0000
committerrlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-05-16 19:09:47 +0000
commit414717ef8c0f9ffb6b34dc36629624134fec0536 (patch)
tree343114f8667a7e9b6a529dd3a947e6562ef602e3 /sync/syncable/dir_open_result.h
parent430ea5f0f3a35406be69c16b96355b409ccecf07 (diff)
downloadchromium_src-414717ef8c0f9ffb6b34dc36629624134fec0536.zip
chromium_src-414717ef8c0f9ffb6b34dc36629624134fec0536.tar.gz
chromium_src-414717ef8c0f9ffb6b34dc36629624134fec0536.tar.bz2
Sync: Clear IS_UNSYNCED for deleted local items
Prior to this change, if we were to delete a newly-created item before informing the sync server of its existence, it would end up in an unusual state. We do not commit deleted items unless they were known to sync server. However, these items were still considered to be 'unsynced' (ie. waiting to be committed to the server) and therefore impossible to entirely remove from the sync directory. They remain forever both IS_DEL and IS_UNSYNCED. This had a few side-effects. The most serious is that this behaviour could cause directory corruption. If we created a folder and a bookmark within it, then deleted that bookmark before it had a chance to sync, the bookmark would remain in a zombie state. When we finally got around to committing its parent folder, the folder's ID will change. The zombie bookmark's PARENT_ID will not be updated, leaving us with a dangling reference that will be detected as directory corruption the next time sync is loaded. See crbug.com/125381 for details. Another effect is that locally deleted, never synced UNIQUE_CLIENT_TAG could have strange effects later on. If a foreign client were to create an item with the same UNIQUE_CLIENT_TAG and sync it, this client would conflict-resolve the update against the zombie entry. The zombie entry would win, the newly created item would be deleted, and the deletion synced back to the server. This may not be an entirely bad thing, but it is a behaviour that's changed following this patch. From now on, the deleted item will be overwritten (if it still exists, which it probably won't). Finally, we now have a mechanism for permanently deleting these items. With this patch applied, these items will no longer have the unsynced bit set, so they will be deleted on restart by DropDeletedEntries(). This patch changes PutIsDel() to clear the IS_UNSYNCED bit of entries which were never committed to the sync server. The remainder of the changes either add or update existing tests. BUG=125381 TEST=SyncerTest.ClientTagUncommittedTagMatchesUpdate, SyncableDirectoryTest.ChangeEntryIDAndUpdateChildren_DeletedAndUnsyncedChildren Review URL: https://chromiumcodereview.appspot.com/10389103 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137476 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'sync/syncable/dir_open_result.h')
-rw-r--r--sync/syncable/dir_open_result.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/sync/syncable/dir_open_result.h b/sync/syncable/dir_open_result.h
index f298ff0..8fe5171 100644
--- a/sync/syncable/dir_open_result.h
+++ b/sync/syncable/dir_open_result.h
@@ -15,6 +15,7 @@ enum DirOpenResult { NOT_INITIALIZED,
FAILED_DISK_FULL, // The disk is full.
FAILED_DATABASE_CORRUPT, // Something is wrong with the DB
FAILED_LOGICAL_CORRUPTION, // Invalid database contents
+ FAILED_IN_UNITTEST, // For tests.
};
} // namespace syncable