[Dev 2513] Stonehearth unable to deal with symlinks

Since 2513, Stonehearth seems to dislike being started from within symlinks (mklink /D or mklink /J). Attempting to do seems to confuse the executable with weird paths (along the line of {{REAL_PATH}}{{SYMLINK_PATH}}, e.g. if the link was C:\Games\Stonehearth -> Steam, the attempted path would be C:\Program Files(x86)\Steam\steamapps\common\Stonehearth\Games\Stonehearth\).

The game will crash with either ambigious messages (“Error starting application” + the invalid path, with or without stonehearth.json) or a boost::filesystem error.

Steps to reproduce:

  • Create a new symlink that points to the directory containing Stonehearth (mklink /J or mklink /D, both don’t work), either across partitions/drives or on the same.
  • Attempt to start Stonehearth from within the new symlink.

Expected Results:
The game starts.

Actual Results:
The game seems majorly confused about its whereabouts.

Sometimes, I also get a boost exception, boost::filesystem::read_symlink: Access denied: "/Program Files" (the first part of the real folder path, D:\Program Files\Steam\...). Tested from any symlink on either C: or D:.

Starting the game as administrator doesn’t help, neither does it make a difference whether x86 or x64 is started.

This is an issue because some people like to have their Steam games somewhere different using a symlink - nowadays, you can choose where you want to install your games, so it’s not as relevant as it used to be. Still, I’m pretty sure that this setup used to work until very recently. I did delete my shortcut to the game, which might have launched it directly from the original folder, but I somewhat doubt that.

All symlinks used absolute paths. No relative paths.

Versions and Mods:
2513, vanilla. Just re-downloaded it into an empty folder to make sure.

System Information:
Windows 7 SP1, all partitions involved are using NTFS.

1 Like

yep, absolutely reproducible

just out of curiosity: why do you use a symlink on Windows?

1 Like

This is fun, because symlinks work in Wine. :stuck_out_tongue:

but unless you try running Stonehearth on a unix system you could still go with “shortcuts” on Windows with the same result as symlinks… with the only difference that the game will start if you call it from a shortcut ^^

My main drive is an SSD, a rather small one. I therefore symlink any program that insists on going into C:\ on another drive - at least all those that aren’t performance critical.

Steam is just the same; my Steam library is quite a few dozen GB that would be completely wasted on an SSD. Therefore (and back before Steam had multiple libraries as it does now) I’ve symlinked steamapps to an HDD.

Other than that, it’s really handy to get hubs going - sort of like Windows’ libraries, but more “native”. You can quickly switch between folders and programs can deal with it rather better, too. There’s lots of reasons to use symlinks to make one’s life easier.

1 Like

not to detail your report, but I may hit you up for some assistance in doing this for my PC…

small SSD, that is super fast for my OS, but a gigantic external drive that is hardly being used…


Am I the only one here who doesn’t know what a symlink is?

wanders out of the room awkwardly


dont worry, your not alone… i’ve just been sitting here silently trying to figure it out…


A symbolic link (or a symlink) is a file that contains the location of a program or folder, but that when called runs that program/opens that folder. It’s useful for organizational purposes. If you have a Windows machine, it’s kinda like making a “shortcut”. (On Macs I think they are called “aliases”.) You can make “shortcuts” for lots of programs/games/apps that you use frequently and put them on your desktop because you want to easily find them. The actual programs aren’t on your desktop, and if you delete them, you haven’t deleted the program, because they are just a symbolic link.


thanks for the description of what symlinks are @greene, it makes much more sense now.

Simply said, symbolic links are like shortcuts. They’re pointers, fake folders. If you have a symlink from “C:\Games\Stonehearth” to “C:\Program Files (x86)\Steam\steamapps\common\Stonehearth”, all programs can access C:\Games\Stonehearth just like it was a normal folder. However, once you do, the filesystem “redirects” you to the real folder (note that you still think you’re in C:\Games - the filesystem just manages to “translate” your requests). You might think that you are in C:\Games\Stonehearth\mods, but in reality, you’re shown the content of Steam’s mod folder. This all happens at a filesystem/operation system level, so usually all programs just deal with it like it was a normal folder (which they don’t with shortcuts, because those are more or less just for the Windows Explorer).


This is still an issue in Alpha 11. And just got me again.


It still works in Wine.