Sounds like a good idea.   Can you give a bit more info on how to use mklink?  
 
It would seem that you delete the actual windows directory (folder), and replace it with a symbolic link?  
 
So for example, Overloud made something called c:\ProgramData\Overloud and put stuff about REmatrix, BREVERB, TH2 in it.   I should move whatever is there to another drive, then make a link:   mklink /j C:\ProgramData\Overloud D:\mybigdrive\Overloud_crap  ? 
 
And down in C:\users\myname\appdata\roaming\Cakewalk, move all that stuff to a big drive and then
 
mklink /j C:\users\myname\appdata\roaming\Cakewalk  D:\mybigdrive\Cakewalk_crap  ?
 
edited to correct mklink option according to following comment ... so if others see it, it will be right.
 

I use  mklink  with the /J(junction) argument.
It's a special link(says junction but is actually a hard link to a Directory on another [local] drive).
The /d argument, I believe, is a hard link to a File.

williamcopper
Sounds like a good idea.   Can you give a bit more info on how to use mklink?  
 
It would seem that you delete the actual windows directory (folder), and replace it with a symbolic link?  
 
So for example, Overloud made something called c:\ProgramData\Overloud and put stuff about REmatrix, BREVERB, TH2 in it.   I should move whatever is there to another drive, then make a link:   mklink /d C:\ProgramData\Overloud D:\mybigdrive\Overloud_crap  ? 
 
And down in C:\users\myname\appdata\roaming\Cakewalk, move all that stuff to a big drive and then
 
mklink /d C:\users\myname\appdata\roaming\Cakewalk  D:\mybigdrive\Cakewalk_crap  ?
 

Yes, other than the argument change you would be correct.
Make sure that the folder you make the junction to DOES NOT exist when you
enter the mklink  junction command, or you will get an error message.
 
A word of caution: once you have committed to this be aware that Windows will treat
the link as though it were a real Directory...
 
DO NOT use Explorer to delete the link if you use any OS previous to Windows 7.
Explorer will traverse the link and delete the entire directory AND it's contents.
 
Use an Administrative dos prompt with rmdir  to delete it after changing to the directory where
the junction link exists.
 
An even safer way to work around this would be to just change the name of the destination
folder(directory) before deleting the link. Then you could safely delete the link with Explorer
without damaging your files.
 
 
Mel
 
P.S. With regard to deleting the original folder on your C Drive;
It's a good idea to back up the folder before doing so in case you make a doodie.

I don't have access to some files at the moment but I keep a text file with the various scripts that make the links I want. All I need to do is copy them and paste them in the Command Prompt when necessary. Eg if I was to accidentally delete one or have to amend a location or reinstall etc.

I'm going to tout this again http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html which allows you to do the mklink (and more) from within Explorer.

KPerry
I'm going to tout this again http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html which allows you to do the mklink (and more) from within Explorer.

You say tout it again so I must have missed it the first time. Must check it out. Thanks Kevin.

First edit:
Checked it out and it looks daunting with all the pics and documentation compared to just a few lines in the command line to use mklink. More reading required.
Second edit:
I've now read quite a bit of the documentation that comes with LSE. It's seems worth creating a thread espousing its value to Sonar users and providing the link back to the original website.

What do others think?
I didn't mean to hijack your thread WilliamCooper but it's pretty much where you're heading I think. Let me know.

I'm glad that I suggested this back in Jan as I recall, but stated then that I was unwilling to do the experiment due to all the other problems. I've used mklink  via a shell extension (probably the one above) for Steam for years in MS (decades in Linux and Unix, but CW is quirky. (No browser text for compressed dir's, etc., for instance, the whole 8.3 filename CLSID thing that still throws errors on Z3ta every time I start SPro, etc)
 
It appears that this is working so far for other folks, so I'll put "link's" on the Sonar maintenance  to-do list. I won't even try to check until I've got Win10 running and my new fiber internet running in August maybe, but this does seem to address a lot of concerns with Sonar. 
 
I'd sure like to see a confirmation from Cakewalk supporting this tool or better yet explaining any issues that they may be aware of, as that did not happen last time I suggested this alternative for those of us with SSD C: drv's and are concerned with capacity, temp file locations, and write duty cycles. 

I haven't used this tool at all, but I have been using mklink not just for bulky data but for VST/I plugins for better organisation and smoother updating. No issue during Sonar's operation nor during new installations which seem to have no difficulty reading the data from it's symbolic location.
Mklink is a Windows command so I can't see a problem with it. I don't think you'll get "permission" from Cakewalk, they often remain silent on these matters. As for the LSE (link she'll extension) program that I think you're talking about (mentioned above by KPerry) I guess it will be up to enough of us to use it and convince others to do so also. Again I can't see anyone from Cakewalk authorising it and if they did it would limited in their not carrying any responsibility if the wheels fell off. For the kinds of files/folders we want to push around, I can't see anything worse than an incorrect link being made generating an immediate error or an improper link making some plugin or sample unavailable. I can't think of anything worse. There is the possibility of deleting data inappropriately but that's the case with anyone who has access to a delete key.

mudgel

What do others think?

What I think is the whole mklink, and above mentioned utility thing, shouldn't even be necessary, just like it isn't necessary for the other 99.9% of the software I/we own, which actually goes where we tell it to, and has the options readily and easily available to do just that.

The last issue I have with mklink (cmdline or shell extension) is that it again spreads data around (though by choice this time). I change storage HW/SW and drives pretty much every year or so. Even worse is the effort required to 'backup' a CW/Sonar installation across multiple drives which has stuff scattered all over anyway. Now, if I had a dedicated PC just for Sonar maybe it isn't so bad. But even that gets tedious. BU'ing a TB data partition (being used by other programs (with their own special needs) in addition to myself for a bunch of data) along with my UEFI (which doesn't help at all) C: drive every month just to keep SPro current is not how my BU schedule is arranged and won't be. And I'm becoming a lot less tolerant of C3 DL issues like this F...Boro release with a dozen individual DL's being required to 'get updated' and no 'Down Them All' option.  A complete BU involves 2SSD and over 6TB's and happens every 4 to 6 months. 
 
I waited 3 years to go from X1(d?) to SPro, and I'm having a lot more than doubts. CW has another 6 months to work things out, but I'm perfectly prepared to go another 3 years with other DAWS if that's how long it will take to get an installation that will be stable for at least one year.

Ease of backup and environment recreation is precisely why I use mklink. All my custom files are in one place and linked into where the need to go. That said, everyone needs to feel comfortable with their computer management and maintenance methods.