Windows Restore corrupts profile data for Win8.1, Win10
Reported by
larrylac...@yahoo.com,
May 6 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.36 Safari/537.36 Steps to reproduce the problem: 1. open a command window as admin 2. do>vssadmin list shadows 3. do>mklink /D C:\shadow3 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ or similar 4. walk down to C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default 5. inspect files What is the expected behavior? Windows restore uses essentially the same steps. Try reading a (large) Bookmarks file. It will probably be full of nulls. Other files fail similarly. What went wrong? This access scenario works fine on Win7. It fails on Win8.1, Win10. The problem appears to be VSS can't walk down the path this deep (in Win8, Win10). Accessing files above Default is OK. Default and below has problems. Only fails for large files (that compress well). Did this work before? No Chrome version: 51.0.2704.36 Channel: beta OS Version: 6.3 Flash Version: Shockwave Flash 21.0 r0 I know this is a Windows issue. But users do restores and then Chrome suffers. Can someone push this up the hill at Microsoft? I'm attaching an email that pretty clearly pinpoints the problem.
,
Aug 5 2016
,
Aug 15 2016
The most likely victim is the Bookmarks file. In my case it contains several nearly identical copies of the same bookmarks, which presumably get compressed by the VSS compression, but don't expand correctly when restored/copied out of the VSS area. Bookmarks file recovery is the only method I know for recovering bookmarks after user or sync bookmark failures.
,
Dec 19 2016
--Chrome Identity automated triaging-- This bug is Unconfirmed and has gone two weeks without any activity, so it is being closed as WontFix. Please re-open if this is still a valid and reproducible bug or feature request and mark it as Available. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 19 2016
The problem with restoring Profile-dir/Bookmarks from the VSS archives is easily reproducible (for large >4K boookmarks files). This is often the only resort for Windows users who have lost bookmarks, which is also a reproducible problem for stale (from infrequently used device or profile) bookmarks. Agreed: this is a Microsoft issue (Win8, Win10). A ref to the MS bug report would be sufficient.
,
Dec 20 2016
Moving to available per comment #5.
,
Mar 28 2017
,
Mar 27 2018
--Chrome Identity automated triaging-- This bug is Available and has gone one year without any activity. If another month passes without any activity, this bug will be closed out. Please provide an update with the latest status for this bug. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 11 2018
--Chrome Identity automated triaging-- This available, signin or profiles-related bug has gone at least 30 days since the last automated post without any further update. This bug will be closed out due to inactivity. Please re-open the bug and provide an update if it is still a valid or reproducible bug. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ranjitkan@chromium.org
, May 6 2016