Finally, this happened to me… I ran something close to
rm -rf ~by accident, and pressed Ctrl+C as soon as I realised something wrong was going on. This blog entry is about how I recovered from this mistake.
Now the detailed version of the accident. I use a standard (non-administrator) account connected to my Microsoft account, and maintain a separate administrator account for privileged activities. My computer rebooted without a clean shut-down so I decided to empty my temporary files folder before signing in to my account. To do so, I sign in to the administrator account and opened PowerShell, then I typed without thinking twice the following excerpt of code:
cd c:\users\gl\appdata\local # !!!
gci -fo -re | del -fo -re
(The line annotated with !!! should have been ...\local\temp.) The administrator account should have no problem removing my temporary files. However, when I ran the commands above, a fast-flowing stream of errors written on the console. I immediately broke the pipeline, but it was too late. I accidentally destroyed my AppData folder.
For those unfamiliar with Windows, this folder usually contains these important things:
- local state of desktop apps, including synched content in Outlook/OneNote and OneDrive synchronisation state
- apps installed exclusively for that user (e.g., Chrome, Visual Studio Code, MiKTeX, SourceTree)
- ‘Start’ (menu/screen) structure, including Windows+X menu items
- state of Store apps
You can imagine what will happen if your apps (and Windows shell) find their internal data completely destroyed. Some of them will recover (e.g., most desktop app preferences just fall back to their defaults), many of them not. For example, Store apps expect APPX deployment service to create an initial clean state and they will maintain consistency, but they cannot start from nothing. In fact, Store apps will simply crash (link in Chinese) if you delete their isolated storage. OneDrive synchronisation state will not match what is inside ~\OneDrive. Start menu and Taskbar will glare into void.
What can I do? The first thing that comes into my mind is to rebuild my user profile. This makes sure I stay in a consistent state, though I have to reinstall per-user apps and reconfigure many preferences, which is OK because many of them are automated. My files (Documents folder and the like) aren’t lost. And even if they are, I’m OK with losing them because all important files are synched to OneDrive or stored on GitHub or Azure DevOps.1
I moved my files under Documents, Music, Pictures, Videos and other places (turns out I forgot Downloads folder, but that’s not a big issue) to other places, used sysdm.cpl to remove my user profile, and signed in again. However, something strange happens. My user account is still connected to my Microsoft account — this is expected because it is stored machine-wide.2 However, for some reason, settings synching and SSO aren’t working. I also noticed that there is no OOBE3 when I signed in to my account (after the profile had been cleanly removed).
This might be a bug of Windows, or lack of design. Microsoft developers might have not thought about the scenario of profile rebuilding on a home computer. To fix this, I logged off and signed in with my administrator account, completely removed the standard account and recreated one associated with my Microsoft account,4 signed out and signed in again. This time everything works right.
Bonus Chatter The rebuilding of my account seems to have mysteriously fixed the mysterious bug of Groove Music not displaying the album covers.
Extra Bonus Chatter I found another bug of Windows during this adventure. If you enable ‘Require trusted path for credential entry’ (i.e., user must press Ctrl+Alt+Del to securely enter a credential), you will be asked to do so when you connect to a Wi-Fi that requires a user name and a password (e.g., eduroam). When you’re doing this signed in, everything is OK and you just enter the credential on the secure desktop. However, when doing this on the Welcome Screen (without having signed in or in the Fast User Switching mode), the dialogue ‘Enter my credentials on the authentic Windows sign-in screen’ will respond to ‘OK’, so you cannot enter your credentials on Welcome Screen — you cannot connect to eduroam on Welcome Screen if you enabled the security policy. This is so sarcastic because Welcome Screen is part of the secure desktop. (FYI, I was using Windows 10 version 1809 Education.)
↩1 Azure DevOps was formerly know as Visual Studio Team Services, or Visual Studio Online even earlier.
↩2 Once your local account is connected to Microsoft account, Windows assigns Microsoft account provider as the authority of that account. Thanks to this, you can sign in to Windows using your Microsoft account password, even if it is changed elsewhere. This also means you cannot change the password of that account using ‘Change a Password’ procedure of Windows Security dialogue. Your account can be represented as either DESKTOP-123456\user or MicrosoftAccount\someone@example.com, and a network SID is added to your account. This is by design, and AAD accounts work similarly.
↩3 This is the ‘Hi’, ‘We’re getting everything ready for you’, ‘This might take several minutes’ screen. In the Chinese version, Windows recites poems from ancient times.
↩4 It will be wise to open lusrmgr.msc and edit your account name before signing in. By default, an account created for a Microsoft account gets the first 5 letters of your e-mail address as the local user name, which could read strange.
Furthermore, you want to make sure the folder of your previous user profile has been removed, otherwise you will get the dreadful user.DESKTOP-123456 folder.
Please enable JavaScript to view the comments powered by Disqus.