Windows 10: Update failed due to linked User directories

For better durability and optimized space usage of SSD's, I had linked my Windows User directory C:\Users\barco to E:\Users\barco using Windows's built-in command-line tool `mklink`.

And this caused an update failure recently, collected by SetupDiag (downloaded from this Windows website), as shown below:


```

2019-05-08 16:43:16, Info MIG Processing profile: C:\Users\barco

2019-05-08 16:43:16, Info MIG Detected profile with linked profile root: C:\Users\barco => E:\Users\barco

2019-05-08 16:43:16, Info MIG Adding extra mapping: C:\Users\barco => E:\Users\barco

2019-05-08 16:43:16, Info MIG Offline platform: adding mappings:

2019-05-08 16:43:16, Info MIG AdjustPrivilege: Privilege SeTakeOwnershipPrivilege will be Disabled

2019-05-08 16:43:16, Info MIG Privilege has been disabled

2019-05-08 16:43:16, Info MIG AdjustPrivilege: Privilege SeSecurityPrivilege will be Disabled

2019-05-08 16:43:16, Info MIG Privilege has been disabled

2019-05-08 16:43:16, Error MigCreateFileVerifier caught exception. Unable to initialize the file verifier.: Win32Exception: E:\Users\barco: 系统找不到指定的路径。 [0x00000003] class UnBCL::String *__cdecl UnBCL:ath::GetLongName(const class UnBCL::String *)

2019-05-08 16:43:16, Error SP CCompressOldOS:oExecute: Cannot create the file verifier. Error: 0x00000004

2019-05-08 16:43:16, Info SP CCompressOldOS:oExecute returns: 0x8007001F

2019-05-08 16:43:16, Info SP DISKSPACETRACK: 11767939072

2019-05-08 16:43:16, Info SP SetupPlatform: Global progress: 0, Phase progress: 3

2019-05-08 16:43:16, Error SP Operation failed: Compress old OS. Error: 0x8007001F[gle=0x000000b7]

2019-05-08 16:43:16, Error SP Operation execution failed: 12. hr = 0x8007001F

2019-05-08 16:43:16, Error SP ExecuteOperations: Failed execution phase Safe OS. Error: 0x8007001F

2019-05-08 16:43:16, Error SP CSetupPlatformPrivate::Execute: Execution of operations queue failed, abandoning. Error: 0x8007001F

2019-05-08 16:43:16, Info Persisting diagnostics data to C:\$WINDOWS.~BT\Sources\Diagnostics\diagnostics.dat

2019-05-08 16:43:16, Info Diagnostics data saved successfully

```


Within which, "系统找不到指定的路径。" means system cannot find the specific directory (or path), in our language.


Though it could be solved by:

1. Enable and log into Admin account;

2. Temporarily remove the user directory link (NOT copying back NOR deleting actual files);

3. Install update and end up back in Admin account;

4. Recover the link;

5. Go back to my account and disable Admin account.


It's still rediculous of Microsoft to fail an update only for to such nonsense. Symbolic links are said to be "transparent" from a low layer and here where's the transparency? By the way, why is hibernation swap file also restricted to C drive? Why does Visual Studio insist to install its most files onto C drive even I've selected another drive? Why does Windows loves C drive that much? Does it suppose that Mic****ft stuff members are likely to be involved in Car accidents or what? Look, I didn't say that, you guessed!

:)

 

Update failed due to linked User directories

For better durability and optimized space usage of SSD's, I had linked my Windows User directory C:\Users\barco to E:\Users\barco using Windows's built-in command-line tool `mklink`.

And this caused an update failure recently, collected by SetupDiag (downloaded from this Windows website), as shown below:

```

2019-05-08 16:43:16, Info MIG Processing profile: C:\Users\barco

2019-05-08 16:43:16, Info MIG Detected profile with linked profile root: C:\Users\barco => E:\Users\barco

2019-05-08 16:43:16, Info MIG Adding extra mapping: C:\Users\barco => E:\Users\barco

2019-05-08 16:43:16, Info MIG Offline platform: adding mappings:

2019-05-08 16:43:16, Info MIG AdjustPrivilege: Privilege SeTakeOwnershipPrivilege will be Disabled

2019-05-08 16:43:16, Info MIG Privilege has been disabled

2019-05-08 16:43:16, Info MIG AdjustPrivilege: Privilege SeSecurityPrivilege will be Disabled

2019-05-08 16:43:16, Info MIG Privilege has been disabled

2019-05-08 16:43:16, Error MigCreateFileVerifier caught exception. Unable to initialize the file verifier.: Win32Exception: E:\Users\barco: 系统找不到指定的路径。 [0x00000003]
class UnBCL::String *__cdecl UnBCL:ath::GetLongName(const class UnBCL::String *)

2019-05-08 16:43:16, Error SP CCompressOldOS:oExecute: Cannot create the file verifier. Error: 0x00000004

2019-05-08 16:43:16, Info SP CCompressOldOS:oExecute returns: 0x8007001F

2019-05-08 16:43:16, Info SP DISKSPACETRACK: 11767939072

2019-05-08 16:43:16, Info SP SetupPlatform: Global progress: 0, Phase progress: 3

2019-05-08 16:43:16, Error SP Operation failed: Compress old OS. Error: 0x8007001F[gle=0x000000b7]

2019-05-08 16:43:16, Error SP Operation execution failed: 12. hr = 0x8007001F

2019-05-08 16:43:16, Error SP ExecuteOperations: Failed execution phase Safe OS. Error: 0x8007001F

2019-05-08 16:43:16, Error SP CSetupPlatformPrivate::Execute: Execution of operations queue failed, abandoning. Error: 0x8007001F

2019-05-08 16:43:16, Info Persisting diagnostics data to C:\$WINDOWS.~BT\Sources\Diagnostics\diagnostics.dat

2019-05-08 16:43:16, Info Diagnostics data saved successfully

```

Within which, "系统找不到指定的路径。" means system cannot find the specific directory (or path), in our language.

Though it could be solved by:

1. Enable and log into Admin account;
2. Temporarily remove the user directory link (NOT copying back NOR deleting actual files);
3. Install update and end up back in Admin account;
4. Recover the link;
5. Go back to my account and disable Admin account.

It's still rediculous of Microsoft to fail an update only for to such nonsense. Symbolic links are said to be "transparent" from a low layer and here where's the transparency? By the way, why is hibernation swap file also restricted to C drive? Why does
Visual Studio insist to install its most files onto C drive even I've selected another drive? Why does Windows loves C drive that much? I suppose that C stands for Car aCCident, hopefully.

 

Update failed due to linked User directories

I routinely move user data to different drives, using one of these methods:

• Set an alternative profile folder location here:
  
  HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory
• Create a symbolic link
• Move individual libraries such as Documents, Music etc.

I found that all of them cause problems with automatic updates. The third option causes the least problems, so I now use it all the time. The first two options I was forced to abandon.

 

Update failed due to linked User directories

So it was not symlink itself causing the trouble, but none-C drives? Your 1st option seems to be without a symbolic link.

Other than Musics and Documents folders, the hidden folder AppData and several other things (created by both Windows and third-party softwares) use the most space of user folder. And there're lots of frequently changing files that are bad for SSD duration.
It's still recommended to link the whole user folder. Whenever a major update (e.g. 1803->1809, whereas an update without that number changing is minor) is needed, you can go to Admin account and delete the link temporarily.