Enabling and disabling SyncDisabled breaks local sync mode |
||||||||||
Issue descriptionI've made some tests and found out that once SyncDisabled was set to Enable, reverting it back to "Disabled" or "Not configured" doesn't restore local sync functionality. Steps to reproduce: 1. Set RoamingProfileSupportEnabled to Enabled 2. Set SyncDisabled to Not configured 3. Delete Chrome user profile (to start from blank) 4. Update & check policy, start Chrome 5. Everything is ok, local sync creates roaming profile file at %AppData%\Roaming\... 6. Set SyncDisabled to Enabled 7. Update & check policy, start Chrome 8. Local sync not working (it is expected): "Local sync backend enabled: true, Local backend path: Uninitialized" 9. Set SyncDisabled back to Not configured (or Disabled) 10. Update & check policy, start Chrome 11. Local sync not working: "Local sync backend enabled: true, Local backend path: Uninitialized" Killing Chrome profile "fixes" this issue. Tested on Chrome 57.0.2987.133 (x64), Windows 7. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Apr 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f51a09272db6c06dcca92fa0e2c4811dc8d5e828 commit f51a09272db6c06dcca92fa0e2c4811dc8d5e828 Author: pastarmovj <pastarmovj@chromium.org> Date: Tue Apr 25 08:33:04 2017 Allow sync to resume in local backend mode after it has been disabled. If sync has been disabled manually or by policy it was not resuming in local sync mode afterwards because there is no external event to trigger that. BUG= 707181 TEST=components_unittests Review-Url: https://codereview.chromium.org/2810943007 Cr-Commit-Position: refs/heads/master@{#466926} [modify] https://crrev.com/f51a09272db6c06dcca92fa0e2c4811dc8d5e828/components/browser_sync/profile_sync_service.cc [modify] https://crrev.com/f51a09272db6c06dcca92fa0e2c4811dc8d5e828/components/browser_sync/profile_sync_service_unittest.cc
,
Apr 25 2017
,
Jun 21 2017
Seems like it still don't work on old profiles (created with SyncDisabled and before RoamingProfileSupportEnabled appeared in Chrome). Is there a way to enable local sync on such profiles besides deleting them? Tested on Chrome 59.0.3071.104 (x64), Windows 7.
,
Jun 21 2017
Actually this should not be a problem. Please run chrome from the command line with the following parameters "-enable-logging=stderr --v=2 > log.txt 2>&1" and upload the log.txt file that will be created. Feel free to remove anything that you might consider personal or sensitive information (in general none should be present except the signed-in user email if any). Also please provide the contents of chrome://sync-internals . I will try to see what causes Chrome to not start properly in your case. Best, Julian
,
Jun 23 2017
I've run it with "-enable-logging --v=2" in shortcut's properties instead. Hope it doesn't matter. See attached chrome_debug.log & sync-internals.png. RoamingProfileSupportEnabled is set to Enabled. SyncDisabled is set to Disabled (also tried other values). Newly created profiles are ok.
,
Jun 23 2017
This is indeed weird. Looking at the code the state of the browser as represented in the logs you uploaded should be impossible in local sync mode. Can you please do a few more tests for me: 1. Give me the list of policies currently applied on the browser (you can see this by opening chrome://policy). Feel free to remove any personal information from them. 2. Try removing (setting to "not set") the SyncDisabled policy and the "RoamingProfileEnabled" policies. Then run the browser by applying "--enable-local-sync-backend" flag. You can combine this with the logging flags as last time to get the logs of this test too.
,
Jun 27 2017
Here they are. Policies screenshots were taken before changes you mentioned in #2.
,
Jun 30 2017
Having the same issue. I narrowed it down a little: * I backed up and then deleted the "Default" profile folder * Started Chrome to recreate it from scratch and with everything reset to defaults * Quit Chrome * Restored file by file gradually from the backed-up Default folder * Started Chrome and had a look at chrome://sync-internals after every restored file As far as my observations go, only the "Preferences" file from the profile causes the problem, if the profile "breaks" local sync. So for a quick&dirty workaround until a bugfix is released, I am basically able to back up everything except the "Preferences" file; memorize/write down the settings that are important or which I have changed from default values; delete the "Default" profile folder and let Chrome create a new one; recreate all browser settings manually; quit Chrome, restore my backed-up files; voilà, no profile data lost and local sync works flawlessly. I was able to reproduce this on two machines, so I'm quite positive that this issue is somehow connected to the Preferences file. Hope this helps anyone in some way!
,
Jun 30 2017
Can you please upload the Preferences file that causes this to happen? Check for some personal info there but if I remember right only the usernames (emails) of the signed in users in Chrome (not in web sites) might be present in the file.
,
Jun 30 2017
Of course, please find it attached. From my yesterday's tests, as soon as I overwrite the Preferences file in the freshly created profile, local sync goes stale. The original profile is several years old (AFAIR created around Chrome 20.x), so there may quite a bunch of trash have accumulated in the file.
,
Jun 30 2017
Edit: [..]as soon as I overwrite the Preferences file _with the one attached_[..]
,
Jun 30 2017
Thanks for the info! Your help is greatly appreciated! :) I really don't see a reason for the state your browser gets in when this Preferences file gets read. It doesn't contain any sync related weirdness. And for a few years old profile it looks really tidy! One last thing that I'd like to try to check the last possibility I can currently think of - please start the browser from the command prompt with the --enable-local-sync-backend (regardless with or without the policy) when the file is already in place. Does this change anything or still observing the same issue? You can also append the --enable-logging --v=2 flags and upload the chrome_debug.log file again. Based on the outcome of this last experiment I will actually file a new bug describing this issue because although it ends up with the same effect it seems to be a completely different mechanism. Thanks again for the cooperation!
,
Jun 30 2017
You're welcome, thanks likewise for the quick reaction! :) I attached a chrome_debug.log and a dump from the chrome://sync-internals for each scenario. The files suffixed with -old-pref-file are recorded with the old Preferences file in place and stale local sync; the files suffixed with -fresh-pref-file are obviously recorded with a "vanilla" preferences file and local sync working. Hope this helps! :)
,
Jun 30 2017
And of course you are right, this issue seems to be kinda unrelated to the initial problem with policies - for my case, I haven't fiddled around with policies at all during my tests.
,
Jun 30 2017
...sorry, I just realized I read your question wrong. Please find attached another debug log file from a session with the "defect" Preferences file in place, and Chrome started including the --enable-local-sync-backend parameter. The status page still shows the "Uninitialized" status for the local sync database, even though the profile.pb file still exists from previous, working local syncs.
,
Jun 30 2017
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=738430. This is very puzzling indeed but I must admit the only way to go ahead with this is to try to somehow recreate this situation locally. Please follow the new bug as I will post any further updates there. Until I get something I am afraid the best advice I can give is to indeed get rid of this file and then reinstall whichever extensions you wish and restore the settings as you like them. To put in a positive light - this will allow you to clean up a bit and get back some speed lost in extensions you might not care about anymore :)
,
Jul 3 2017
Thanks for taking care, and of course you are right - I am migrating my users/PCs to a Windows domain currently, during which I discovered this error, and since I have to get my hands on every PC in the office anyway, it's definitely a good way to clean things up for my users a little. :) |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by pastarmovj@chromium.org
, Apr 13 2017