Install issues with C:\Users as a symbolic link to D:\Users

[Sembazuru]

I discovered this issue earlier this year, but was recently bitten by it again so I thought I should report it.

I have the 2013 LabView Student Edition that was bundled with an Arduino from Sparkfun. My computer has a SSD as C: and a magnetic HDD as D:. I'm familiar with Linux (Debian) and like the idea of Users fully being on a separate drive from the OS install to make backing up not only my data but also my settings easier. I have my entier Users folder on 😧 and a symbolic link (mklink /D) on C:. Nothing I've installed or used seems to have a problem with this configuration, that is until I first tried to install LabView 2013. The installer actually converted the symbolic link to a directory which as you can imagine breaks all sorts of things in Windows. I have to go into recovery mode to resetablish the symbolic link.

I got through that, but recently installed 2014 NI package manager so I could upgrade to the latest LINX and came across the same bug. (Installing the latest LINX did not trigger the bug, just the install of NIPM.) I finally reaiized what was wroing after freaking out that someone sniffed my network traffic and hacked my Microsoft account because I had just used a public WiFi at a local library without sending my traffic through an encrypted VPN tunnel...

I'm not sure how to get more details on this bug, and I'm not really keen on trying to duplicate due to the hassle required to recover. Hopefully someone in NI can track this down and squash it.

[beccamir]

Hey Senbazuru,

I have a couple questions for you:

1. Are you dual booting where 1 drive is dedicated to Windows and the other is dedicated to Linux?

2. How are the operating systems installed on the hard drives?

3. At which point does the symbolic link file become replaced?

4. Which folder replaces that file?

Also, have you tried installing all of the NI software before creating the symbloic link?

[Sembazuru]

I'm sorry if I caused confusion. I only have one OS installed on my computer, Win8.1Pro as factory installed when I purchased this computer at the end of January. (This is a Dell Precision M4800.) I only mentioned Linux because I was trying to force Windows to emulate the spirit of having the users folder on a separate partition or drive than the OS to allow simpler backups that would also include the user-specific application settings. (Even with that, I found that it was a bit of a chore to get some backup programs to recognize and backup the AppData folder...)

As far as how I have my OS installed, except for the Users folder it is a standard install to C:\. Here is the directory listing from the root of my C:\ drive:

 Volume in drive C is OS
 Volume Serial Number is 8E54-D7F5

 Directory of C:\

2015-01-22  04:34    <DIR>          Apps
2015-01-29  00:42    <DIR>          Brother
2015-01-22  05:11    <DIR>          DELL
2015-01-22  04:30    <DIR>          Drivers
2015-05-19  00:58    <DIR>          Intel
2015-02-02  01:45    <DIR>          National Instruments Downloads
2015-02-25  00:50    <DIR>          Numerical Innovations
2013-08-22  11:22    <DIR>          PerfLogs
2015-06-04  00:12    <DIR>          Program Files
2015-07-04  15:51    <DIR>          Program Files (x86)
2015-04-20  00:04    <DIR>          Python34
2015-06-22  03:29                 0 Recovery.txt
2015-06-03  23:50    <DIR>          TEMP
2015-06-22  03:47    <SYMLINKD>     Users [D:\Users]
2015-06-27  19:18    <DIR>          Windows
               1 File(s)              0 bytes
              14 Dir(s)  165,903,974,400 bytes free

When I installed the 2013 LabView version from SparkFun back in early February, I forget at what point the install broke, or even how many times it may have happened. But it happened again recently (a couple weeks ago) when I installed NI Package Manager 2014 so I could upgrade my old Linx to the latest Makerhub Linx. I wasn't able to install the Linx package until after I fixed the Users folder back to a symbolic link pointing to D:\Users.

When the issue happens the C:\Users symbolic link is replaced with a folder called C:\Users, but none of the data from D:\Users is copied over. So, pretty anything else that requires loading information from AppData fails or creates a new AppData tree with default settings. And when trying to log in again to Windows fails with "The User Profile Service failed the logon. User profile cannot be loaded."

I have not tried installing any NI software with a more stock setup. The first thing I did after the initial power-up and requisite system updates was to log into recovery mode, copy the Users folder from C:\ to D:\, rename the C:\Users to something else just in case, and then make the link. Once I verified that everything seemed to work I removed the original C:\Users and started installing other software that I use regularly. The NI install wasn't until about the last quarter of software installs, and it was the only one that had an issue with my symbolic link. Since then, NI installs are still the only ones that have an issue with my symbolic link.

[beccamir]

Sembazuru,

Are you using a soft link or a hard link?

[rolfk · Accepted solution]

Using SymbolicLinks under Windows for Program Installation paths is strongly discouraged by Microsoft itself as it will break various things, not just confusing installers. They specifically disallow that for several locations because of this. Symbolic Links, while theoretically possible since about NTFS V3 only appeared in Windows Vista and are even in Windows 7 a rather hidden feature. Hidden enough that it doesn't get used often and still has numerous quirks.

Windows Installer Component and Wiindows Component Services still have trouble to work properly with Symbolic links, which makes it hard for Software Developers to create standard installers that can actually work properly when targetting paths which contain Symbolic links.

Your Linux background most likely plays tricks on you here. While symbolic (and hard) links are an inherent feature of almost every Unix file system driver since its early inception, it is still a seldom exercised feature under Windows, other than for some internal to Windows file virtualization for User file locations.

An interestying read is this wiki article whiich details some of the possible problems with Symbolic Links even under the most recent versions of Windows. An interesting point for instance is that redirecting Program Files will basically make any Windows Upgrade fail catastrophally.

[Matthew_Kelton]

As Rolf has alluded to, Windows links are not quite the OS level trick Microsoft makes it out to be.  There seem to be several instances where the OS isn't properly handling the links or junctions.

I have had issues doing it as well, as I have a similar setup as you where I have several directories on my HDD (D:) and not on my SSD (C:).

Have you tried Junctions instead of Sym Links?  I originally had everything as symlinks and ran into some issues that escape me at the moment.  I switched over to junctions and the problems went away.

Of course, with junctions, I recently had issues with LabVIEW FPGA compiling.  It appears that Xilinx is able to determine the junction's true path, and was switching between C:\FPGA and D:\FPGA, ultimately failing to build.  I switched that back to a symlink and now Xilinx is fooled again, and everything works as it should.

[Sembazuru]

Well, after reading the dire warning on the Microsoft bullitens (which basically read as "here are some really good reasons to move the users folder to another drive, but you shouldn't because our filesystem is broken") I decided to move users back to C and have my libraries (documents folder, music folder, etc) "relocated" to D.

Unfortunately, due to a typeo with robocopy I ended up wiping my C partition clean... I'm currently reinstalling all my crap. It's almost enough to convince me to switch to Linux...

[Intaris]

I was just reading up on this last night.

I also wanted to put my users directory on a separate dat disk but reading about all of the incompatibilities with Windows itself (how dumb is that) I thought better of it.

I remember I had an ond system (Windows 2000) where a previous employee had placed a directory on the hard drive and a symbolic link within poi9nting back at C:\.  IT was funny watching MSBackup trying to back up the drive, it stayed at the process of working out the size of the data set because it had started parsing a recursive file system..... MY first indication that not all of MS software work on the same assumptions.

[rolfk]

I doubt that is was a symbolic link under Windows 2000. Most likely he created a junction point, yet another variant of the reparse point in the NTFS spec that allows to redirect parts of a filesystem. Junction points were the first supported variant of reparse points, although Windows itself didn't come with any tools to create them. You either had to install the resource kit and use its command line tool "linkd" or Mark Russinovich's "junction" tool to create them. Junction points only can work within the same volume and only for directories and as such are similar to hardlinks in Unix. One of the main differences between Junction Points and Symbolic Links are that the former is resolved on the server side directly while the latter is resolved on the client side. This means that Junction Points (aside from the possible recursive problem which of course is a system configuration error) the client doesn't have to have any support in any form and flavor to use paths that use them.

Windows before Vista had no build in support for Symbolic Links. You could install a third party device driver that added support for them to Windows XP but to the best of my knowledge there was no support of Symbolic Links under Windows 2000 possible.

As to Backup programs choking on recursive links that is not a Windows only feature. Many Linux programs had that initially too, although since it is so common to have hard and soft links under Unix, they quickly run into this and eventually get fixed. Under Windows the entire legacy architecture that still is present and partly dates back to DOS times just is to involved to make it flawlessly work everywhere.

[Intaris]

Thanks for the clarification, I never really understood the difference between a symbolic link and a junction point....

If anyone can shed light on such windows details, it's Rolfk!