diff options
author | rlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-05-16 19:09:47 +0000 |
---|---|---|
committer | rlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-05-16 19:09:47 +0000 |
commit | 414717ef8c0f9ffb6b34dc36629624134fec0536 (patch) | |
tree | 343114f8667a7e9b6a529dd3a947e6562ef602e3 /sync/syncable/dir_open_result.h | |
parent | 430ea5f0f3a35406be69c16b96355b409ccecf07 (diff) | |
download | chromium_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.h | 1 |
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 |