How to move a Windows 7 VM's CSC to a network/host volume?

Question

I am running a Windows 7 Pro virtual machine on VMware on Ubuntu 14.04, and would like to move the Win7's CSC (client-side cache, for offline files) to the data partition on the Linux host. This is a local volume but regarded by Windows as a network volume.

Available online resources suggest two methods, neither of which (as implemented) seem yet to work.

The first method disables Offline Files, deletes C:\Windows\CSC and its subdirectories, creates a directory junction to the new location, and re-enables Offline Files. This method fails because a directory junction can only reference a local volume, and the CSC does not rebuild when using a directory symbolic link to the host volume instead (mklink /d, instead of mklink /j).

The second method clears the CSC, then creates HKLM/System/CurrentControlSet/Services/CSC/Parameters/CacheLocation = [the target directory]. This prevents Win7 from rebooting. [Good thing it was only a virtual machine that I could re-clone with a few mouse clicks.]

So, the question is, whether it is possible, and how, to move a Windows 7 Pro virtual machine's CSC to a host's volume. Any thoughts would be greatly appreciated.

Answer 1

I've never tried this, but I strongly suspect it cannot be done.

The VMWare Tools inside the VM "fake" network access to the host as evidenced by the fact that you can still access the host (via a UNC path) even if the VM doesn't have network access.

CSC.sys is a low-level system driver that sits at the same level as the network stack. I suspect it loads first so it can do it's thing, and it's smart enough to know the difference between a local volume and a network path (even a "faked" one), since that's the whole point of its existence. The cache location is supposed to be a place of guaranteed access in the event of a network outage. The parameter exists only to place it on a different local volume in the case of a space-constrained C: drive.

Placing the cache location on a network drive (even a faked VMWare one) would be ripping a hole in space-time continuum as far as the OS is concerned. This is probably why Windows won't boot when you try. No one would've thought to correct that bug since it makes no sense (after all, you could theoretically isolate the guest and/or uninstall the VMWare Tools and you'd lose access to the host's volumes as well).

Also, NTFS junctions are not as robust as *nix hardlinks and symlinks are. There are lots of programs that aren't fooled by them. Even Windows Explorer didn't know what to do with them before Windows Vista came out, and the only reason that got fixed was because Microsoft started using them for compatibility with Windows XP.

If you actually manage to make that work somehow I'd love to know how you did it.