Something I learned a while back when dealing with computers in general, was to try to keep my files in a separate drive than the Operating System. The first reason for that is to be able to easily do a clean reinstall of the OS if something goes terribly wrong (which can happen relatively easy if you’re learning UNIX, dealing with obscure Windows features, or doing a lot of software installs/uninstalls), without having to first move/backup your personal documents and similar files. Another reason is to keep disk usage low in the disk/partition where the OS lives. This is particularly relevant when the OS is installed on an SSD drive, which tend to not be huge (compared to HDD drives) and can easily run out of space if we put our decades-old photo/video collection in them.

All the “default folders” that Windows uses for user documents (Documents, Downloads, Desktop, and some others) are pretty easy to move to a different drive. Just browse to C:\Users\<username>\, right click one of those folders, go to the Location tab, specify a new path, and click Move.

And that’s it! You have to do this one by one for each of these Windows-managed folder, but luckily they’re not that many. If you already have a lot of data in them and you ask Windows to move it for you, then be prepared to wait according to how much data there is.

But things don’t end here. Because of the first reason mentioned above, I also want to make sure that configuration files created by applications I use (at least some of them), are also kept in a separate drive. So that after reinstalling the OS and reinstalling my most common tools/applications, I don’t have to recreate my customizations too. However we don’t usually have that much control over where each application decides to write its configuration files.

In the UNIX world this problem is basically nonexistent, because the user’s home directory is where pretty much everything writes configuration files that are specific to the current user. In Windows, many applications write them to wherever the %USERPROFILE% variable points to (by default C:\Users\<username>\). Sometimes directly there, sometimes under a subfolder. Another common location is to write them under %APPDATA% or %LOCALAPPDATA%, which by default are C:\Users\<username>\AppData\Roaming\ and C:\Users\<username>\AppData\Local\. The details of how these two differ from each other are outside the scope of this discussion, but you can apply the same idea that we’re about to see.

So what can we do about those files? At least for some of them, the solution is symlinks! You can think of symlinks as virtual files/folders that you put somewhere, and tell them to point to some other location, so that anything that tries to work (read/write) with the location where the symlink lives, is actually working on the target location, without being any wiser or having to know about the redirection that’s happening.

Let’s see this in action with a real-world example. In my machine I use Windows’ OpenSSH client to connect to remote computers pretty frequently. In order to not have to learn the different parameters, ports, usernames, etc. that I have to use fore each of the remote machines, I like to use an SSH config file. A simple one looks like this:

Host vm1
	Hostname actual-name-of-computer-1.some-domain.com
	User userforcomputer1
	IdentityFile ~/.ssh/id_ed25519

Host vm2
	Hostname actual-name-of-computer-2.some-other-domain.com
	User root
	Port 2222

Which lets me type ssh vm1 or ssh vm2 and have the OpenSSH client take care of the details for me.

The issue is that the OpenSSH client expects to find this file in %USERPROFILE%\.ssh\config, i.e. C:\Users\<username>\.ssh\config. But that file is definitely something that I want to keep with the rest of my data, so a OS reinstall doesn’t wipe it out. And there’s no way to tell this particular application to always look for the config file somewhere else (we can pass an extra parameter to ssh to tell it the location, but then we have to remember to pass that every time; inconvenient). What we can do is create a symlink at C:\Users\<username>\.ssh\ and point it to, say, D:\Users\<username>\.ssh\ (I like to create a similar folder structure in whatever drive I move the stuff to, makes it easy to know where the original locations are). That way the OpenSSH client will keep doing what it always does, but behind the curtains Windows will be actually dealing with files in the D:\ drive instead of the C:\ drive.

To create that symlink, open cmd (specifically cmd, this won’t work from Powershell or other consoles because the executable to create symlinks is part of cmd) and run something like this:

mklink /D "<link location>" "<target file/directory>"

In our example, this would look like

mklink /D "C:\Users\<username>\.ssh\" "D:\Users\<username>\.ssh"

And there you have it! The configuration file is kept safe in the D:\ drive, while OpenSSH still thinks everything is happening in C:\.

This approach works really well for applications that use a subfolder under %USERPROFILE%, and not so well for applications that write potentially many files directly in that folder. You can create a symlink for each file and they’ll work, but you need to know exactly which files to do it for, instead of just symlinking the one folder. And now you ask “Why don’t I just symlink C:\Users\<username>\ directly?”, which is a great question. And the answer might be that you can, but I haven’t convinced myself that it’s completely safe, so I can’t say that you should. If you do a search for this, some sources say that moving the User Profiles folder to another drive will stop Windows Update from working in the future, others say that they’ve done it and had no problem updating, others that it’s only (semi)supported if you do it with special configuration alternatives when installing Windows… it’s also not entirely clear to me if symlinking the profile folder of a specific user also counts as “moving the User Profiles folder to a different drive”. As tempting as it sounds, I haven’t made the time to test it. If you decide want to try this, you’ll probably need to log in with a different account, so you can move all the files for the user whose profile you want to move (otherwise some files could be locked or actively in use) before creating the symlink. And if you do, let me know how it went.

To conclude, note that in case of an OS reinstallation, the files will be safe in the other drive, but you’ll have to recreate the symlinks.