One of the things I did when I had a small SSD as the system drive was:
Open an administrative command prompt and copy large content folders to a different drive. In my case I simply used xcopy to preserve all the file permissions/stamps/etc and copy directories:
Code: Select all
xcopy /E /I /H /K /X /B "C:\ProgramData\Steinberg" "E:\ProgramData\Steinberg"
(note, the /B flag will copy any links/junctions if they exist, rather than making a full copy of their targets.)
Next I renamed the original folder:
Code: Select all
rename "C:\ProgramData\Steinberg" "C:\ProgramData\Steinberg.bak"
Then, I set up a file-system junction:
Code: Select all
mklink /J "C:\ProgramData\Steinberg" "E:\ProgramData\Steinberg"
I ran Cubase/Halion/etc. through a few stressful sessions to make sure it was working properly. Once I was satisfied it worked, I deleted the original folder on my System Drive:
Code: Select all
rmdir /S "C:\ProgramData\Steinberg.bak"
Had it not worked to satisfaction, I'd simply have removed the junction, restored the original directory, and deleted my 'copy':
Code: Select all
rename "C:\ProgramData\Steinberg.bak" "C:\ProgramData\Steinberg"
rmdir /S "E:\ProgramData\Steinberg"
It has worked really well for me...I also used junctions like this to move other large VSTi libraries to alternate drives.
I later did the same for a few directories in my %USERPROFILE% area of Windows, as some of those can grow to be fairly large if you make a lot of complete VSTsound files with samples included.
Richard Herbert wrote:
You can of course tell the installers to install the content to a separate drive at installation time.
Quite true for most (if not all) of the latest Steinberg offerings. That'd be the official way to do it
To run from multiple drives/partitions: I could have used the installers to uninstall, and then reinstall, etc.
I expanded the tactic to other software and libraries as well, and some of them didn't have as flexible installers as Steinberg's, or would simply break if they didn't think they're running from the System Drive.
The nice thing about Junctions....is software thinks it's running from the device that's hosting the Junction pointer, and the OS reflects a file path to that nature. It also makes it easy if you use removable drives and such that you might not always have connected (just fix the junction anytime your configuration changes, without having to reinstall things, or mess with registry hacks). It's not difficult to even make little scripts on a removable devices (I.E. USB stick, or hard drive) that would run when plugged in and check/change/create junctions for you automatically.
Another example is attempting to install something that MUST be installed on the system drive, but there simply isn't enough space for it. In this sort of case, you'd make junctions to some other partition/directory first, and then install the software. It thinks it's going on drive C and just works
It's kind of a last resort option for folks with small system drives. For apps that are easy to reinstall if something goes wrong, there's really not much to lose by trying it if you're just flat out of space on the drive.
There may well be some software out there that does not work well with this sort of file junction
. I.E. I wouldn't dare move anything from the Windows directory this way, and I'd be extra careful if I were using any kind of back-ground drive or file encryption protocols. Any application that likes to create lots of symbolic hard-links to various files or directories on the system partition file-system should not be moved/linked in this way.
If it came from the "MS Windows Store", uses the MS "Component Based Servicing" protocol, or is an app/directory updated by the windows updater system (I.E. MS Office)...keep it on the system drive (don't point to it with Junctions)! Always test it before 'deleting' any original directories or files), but most things will plug right along (particularly large content libraries, temp directories, or user generated files).
With Windows, it's pretty important to use /J (junctions) rather than symbolic 'soft-links' when at all possible (the exception would be if you're trying to run things over a LAN or WAN using direct networking protocols instead of mount points). "Hard Links" can only be used if you're pointing to something that lives on the same partition/drive. "Soft-Links" can point almost anywhere...but if an application demands it run from a specific place (I.E. Drive C), it might get confused, as the soft-link can show the true path to the file (it really depends on how the application addresses file paths in this case...coders have more than one option provided by the OS). Junctions are more like soft-links, BUT, more programs will think it's all running from the device the junction is hosted from, regardless of the protocol the coder might have used to get/manage file path info.
If you use symbolic soft-links instead of junctions, the file path can look a bit different to some apps (showing true paths...more like a short-cut) and confuse some software. Sometimes with symbolic soft-links, poorly done installers/un-installers/updaters will just remove the top most level symbolic link itself (usually a directory pointer) and leave all the actual files in place. I.E. Instead of actually removing "E:\directory1\directory2\somefile.wav", it might just remove the "C:\directory1" symbolic link on drive C, rather than deleting the actual somefile.wav file on drive E.
Finally, when using junctions, note that you 'can' point directly to individual files. I personally would avoid that, and just use pointers to entire 'directories/folders'. My reasoning for this is long and convoluted, but as long we're just linking directories......most of the software out there should think it's living on the drive/partition hosting the junction, and work just fine, while the OS takes care of the rest.
If you use the junctions to milk some more life out of a small system drive:
As always...do regular clones or backups of your system drive...
Make notes when moving and linking things (MYNOTES.txt files in relative directories are good), so if you forget and need to know later, you can refer to your notes. Keep a close eye on things after running any sort of installer or update package to make sure it hasn't broken your links and left trash behind in the target directory (take advantage of installer/uninstaller logs for apps that have them).
http://www.windows7home.net/how-to-crea ... windows-7/