The assumption in my initial post is data already exists in the folder on the C drive but it does not matter. What does matter is prior to issuing the mklink command, the path on the C: drive must not exist and the path on the D: (or whatever drive is actually storing the data) must exist. This is why in the example above, the first step moves the "C:\Cakewalk Content" folder to the D: drive.
 
The process for a new install where "C:\Cakewalk Content" did not exist is
1) create "D:\Cakewalk Content"
2) Run cmd.exe as administrator and type:
mklink /j "C:\Cakewalk Content" "D:\Cakewalk Content"
Then when installing, the installer will think it is writing to "C:\Cakewalk Content" but the OS actually writes everything to "D:\Cakewalk Content." When SONAR starts up it will use the "C:\Cakewalk Content" default setting but the OS actually reads the data from "D:\Cakewalk Content."
 

The assumption in my initial post is data already exists in the folder on the C drive but it does not matter. What does matter is prior to issuing the mklink command, the path on the C: drive must not exist and the path on the D: (or whatever drive is actually storing the data) must exist. This is why in the example above, the first step moves the "C:\Cakewalk Content" folder to the D: drive.
 
 
Huh? So before executing this I should go into Sonar and change the destination folder addresses for whatever I want to move from C to D? I'm OK with leaving the .dll and .exe on C but want the bulk, the MIDI files and Audio files (packs etc) to be on my D drive. I have room on the C drive for now but I want to do it right on my new DAW, in the past I have allowed installers to put things everywhere. I have a 500G C drive, and two other 1T drives, one for samples, midi, etc. The other for projects and audio/midi associated with them, if this makes sense. So... I'm perfectly fine with the VST on C, I want the audio or mido on D and well, you get the idea... does this make sense or does it complicate things? Will what you suggested make CCC put everything on the D drive except Sonar or what? I added post 11 to my Notepad document.
Pretend you're talking to a third grader... I'm sorry.
 
Thanks!
 
J

On my phone here but wanted to make a quick comment to Silk Tone. The advantage of an SSD is fast read times, so programs are best kept on the C drive. Data files are the ones to use a junction on if necessary, specifically video and audio files. Easy way to find the suspect programs that need to be looked at is use windows explorer and search *.* on the C drive for file size = gigantic.

This can be done as/if you see a C drive losing space; but bottom line, I would not recommend blindly junctioning the entire program files folders as it is overkill and bypasses the primary purpose of an SSD (I believe your new comp has an SSD on the C drive).

jbow
At the risk of sounding ignorant (well, about this I AM ignorant, not stupid, I can learn but def ignorant!)... any elaboration will be appreciated. Like "documenting and junction points for dummies". Really, I assume that you mean to just write down where you/I put everything associated with a particular VST, that makes sense.. but if all MIDI and audio associated with instruments goes in subfolders on D drive, under VST Audio and Midi and you direct the .dlls that are on the C drive to their sub folders on the D drive, shouldn't everything work? Then wud I need to set Sonar to just scan the VSTPlugin folder on the C drive? Then C would have a lot of small folders with the big stuff on D drive... or am I not understanding? Would I need to also set to scan the folder on D drive or all the subfoders with audio and midi on D drive?
I hope that makes sense.. 
Thanks you!!
 
J

Junction points are transparent to anything that use those folders/files. If you were to do what scook says and create a junction point for "C:\Cakewalk Content" to some other drive, Sonar will still think those files are on the C drive. So Sonar might want to load a file called "C:\Cakewalk Content\Samples\foo.wav", but underneath the OS will redirect to the other drive and load the file from there without Sonar even knowing.
 
Note the problem is not so much VST locations (which you can thankfully specify in C3), but everything else. This include the actual program executables (Dim Pro, etc) as well as the samples. It is mostly the samples that create problems since they take a lot of space, and sometimes we have dedicated fast SSDs just for samples. But C3 doesn't allow us to choose locations for the applications or the samples, so the only options left are to install everything manually, or resort to tactics like using junction points.
 
EDIT: And to answer your last question... No, you would not need to do anything different in Sonar like directing VST paths to scan on D when you use junction points. They will all think their files are really on C when they aren't, but all will work correctly.

mettelus
On my phone here but wanted to make a quick comment to Silk Tone. The advantage of an SSD is fast read times, so programs are best kept on the C drive. Data files are the ones to use a junction on if necessary, specifically video and audio files. Easy way to find the suspect programs that need to be looked at is use windows explorer and search *.* on the C drive for file size = gigantic.

This can be done as/if you see a C drive losing space; but bottom line, I would not recommend blindly junctioning the entire program files folders as it is overkill and bypasses the primary purpose of an SSD (I believe your new comp has an SSD on the C drive).

Yes all good points. However the system I'm getting has a 500GB SSD for the OS, 3TB MD for applications and all their related junk. Once the system is fully set up, I plan to move my old system's 2 x 256 GB SSDs to the new system as well. So the bottom line is there will be many drives, with one being MD and the rest all SSDs.
 
Alternatively I guess the 500GB C drive should be enough to just let the applications install themselves there, but use junction points to the other SSDs for all the samples. This should give a speed boost when loading applications, so maybe I'll just use the 3TB MD for dumping whatever other stuff I have.
 
Heh, I have a folder on my current system that has all the data I had on all my previous 5 systems or so. The 3TB drive will easily hold all of my current system's data and those old system data as well. Just shows how drive sizes have grown over time, when your previous system data can easily fit somewhere in a folder in case you want to quickly locate some old project or whatever.

jbow
The assumption in my initial post is data already exists in the folder on the C drive but it does not matter. What does matter is prior to issuing the mklink command, the path on the C: drive must not exist and the path on the D: (or whatever drive is actually storing the data) must exist. This is why in the example above, the first step moves the "C:\Cakewalk Content" folder to the D: drive.
 
 
Huh? So before executing this I should go into Sonar and change the destination folder addresses for whatever I want to move from C to D? I'm OK with leaving the .dll and .exe on C but want the bulk, the MIDI files and Audio files (packs etc) to be on my D drive. I have room on the C drive for now but I want to do it right on my new DAW, in the past I have allowed installers to put things everywhere. I have a 500G C drive, and two other 1T drives, one for samples, midi, etc. The other for projects and audio/midi associated with them, if this makes sense. So... I'm perfectly fine with the VST on C, I want the audio or mido on D and well, you get the idea... does this make sense or does it complicate things? Will what you suggested make CCC put everything on the D drive except Sonar or what? I added post 11 to my Notepad document.
Pretend you're talking to a third grader... I'm sorry.
 
Thanks!
 
J

Best advice, start small before trying to reorganize the world. Also think about why you are moving stuff. The initial post in this thread was about moving a large directory of content to free up space on the C drive, It is possible to move all kinds of stuff but to what end? I am not a fan of using junctions to achieve some aesthetic outcome.
 
If you have a particular directory of stuff you want to move, it might be a good idea to practice the concept with it, I can walk you through it if necessary. The process is pretty safe because nothing is being deleted. Generally the worst that can happen is a fat fingered mklink command.

Thanks Scook. I am just in the beginning of setting up a new DAW and want to have it organized instead of having to scan 10 different folders for VSTs. It works, but I could forget or lose something and why not be organized. I assume keeping the C drive lean will make a difference... though IDK. I could, at some point, replace the C with a SSD with a clone of the current 7200 500G drive if I don't put too much stuff on it. I don't know, I just want to be a bit more organized. I assume it can't be a bad thing. Then again, I could just direct CCC to put VSTs on the D drive and manually install third party VSTs on D.
Trying to learn and do things right this time.
 
J

Using CCC path changes for VSTs is a better idea. That and pay attention when installing third party plug-ins making sure they go where you want them. A little planning and care during installation will avoid the jumble of multiple plug-in paths. I would recommend leaving the VST3 path in the CCC at the default setting.
 
Once you get everything installed and still want to move some data such as the DimPro multisamples folder or Cakewalk Content, we can go over the details. Some of this is easier to do after install.

I use junctions when necessary if I want to move large multisample folders or whatever, and they work great. They're not all that obvious in Windows Explorer, though. AFAIK, they're only indicated with the shortcut folder icon, so it's easy to delete files or even the entire folder if you're not thinking and assume they're dupes. I don't know if there's a way to protect against that (would love to know if there is.) You can run the cmd.exe DIR command from the source or whatever they call it directory to see if there's a JUNCTION to a target directory. Windows Explorer still shows n number of files taking up n bytes in the folder. I haven't checked to see how/if the used/free bytes are calculated.
 
I use Everything.exe (http://www.voidtools.com/) to find duplicate files, and that does show where the physical files are located, so just the target folder.
 
-Susan
 
 

Holy crap, this post is blowing my mind. I've used symlinks in various unix hosting situations before but didn't realize we could re-program windows to do the same thing. Hrm...