summaryrefslogtreecommitdiffstats
path: root/sync/syncable
diff options
context:
space:
mode:
authorzea@chromium.org <zea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-06-18 20:14:58 +0000
committerzea@chromium.org <zea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-06-18 20:14:58 +0000
commit74caad6bf68409350454bec97ae74468850a6aca (patch)
tree415e85e06fc2deac3918d6a4592492aba1a79289 /sync/syncable
parent6bdf83ef3369fe6afe434a4a460971e912937460 (diff)
downloadchromium_src-74caad6bf68409350454bec97ae74468850a6aca.zip
chromium_src-74caad6bf68409350454bec97ae74468850a6aca.tar.gz
chromium_src-74caad6bf68409350454bec97ae74468850a6aca.tar.bz2
Revert 142563 - Handle sync database corruption with re-download
A recent change allowed us to handle a missing sync database by creating a new directory and repopulating it by requesting an initial sync from the server. This commit builds on that work by intentionally deleting the sync database if it is found to be corrupt or unusable. The client will then recognize that the database is empty and repopulate it, just as it would had the directory not existed in the first place. BUG=109668 TEST=Manual. Three cases, see below: - Delete 'Sync Data/SyncData.sqlite3' from the profile directory. Start chromium and observe that all data is redownloaded from the server. - Corrupt an existing sync directory. The SQL command 'DELETE FROM metas WHERE metahandle = 1' should be sufficient. Start chromium and observe that the directory is deleted then recreated and all data is redownloaded from the server. - Ensure that no directory can be created. You could do this by marking the 'Sync Data' folder as read-only. Start chrome, and observe that sync is unusable, but the browser still works. NOTE: This only works in release builds, debug builds will DCHECK. It's debatable whether or not this scenario is worth testing. Review URL: https://chromiumcodereview.appspot.com/10554016 TBR=rlarocque@chromium.org Review URL: https://chromiumcodereview.appspot.com/10578003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142793 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'sync/syncable')
-rw-r--r--sync/syncable/directory_backing_store_unittest.cc19
1 files changed, 19 insertions, 0 deletions
diff --git a/sync/syncable/directory_backing_store_unittest.cc b/sync/syncable/directory_backing_store_unittest.cc
index 65dd1e8..5161817 100644
--- a/sync/syncable/directory_backing_store_unittest.cc
+++ b/sync/syncable/directory_backing_store_unittest.cc
@@ -2084,6 +2084,25 @@ TEST_F(DirectoryBackingStoreTest, ModelTypeIds) {
}
}
+// TODO(109668): This had to be disabled because the latest API will
+// intentionally crash when a database is this badly corrupted.
+TEST_F(DirectoryBackingStoreTest, DISABLED_Corruption) {
+ {
+ scoped_ptr<OnDiskDirectoryBackingStore> dbs(
+ new OnDiskDirectoryBackingStore(GetUsername(), GetDatabasePath()));
+ EXPECT_TRUE(LoadAndIgnoreReturnedData(dbs.get()));
+ }
+ std::string bad_data("BAD DATA");
+ EXPECT_TRUE(file_util::WriteFile(GetDatabasePath(), bad_data.data(),
+ bad_data.size()));
+ {
+ scoped_ptr<OnDiskDirectoryBackingStore> dbs(
+ new OnDiskDirectoryBackingStore(GetUsername(), GetDatabasePath()));
+
+ EXPECT_FALSE(LoadAndIgnoreReturnedData(dbs.get()));
+ }
+}
+
TEST_F(DirectoryBackingStoreTest, DeleteEntries) {
sql::Connection connection;
ASSERT_TRUE(connection.OpenInMemory());