Relocating the database and backup folder
 

I would like to relocate the RW's database and other folders to a different disk with better performance. I don't see any way to do it, except using junctions (symbolic links) to the other volume.

%homepath%\Documents\Realm Works -> D:\Realm Works\Data
%appdata%\Roaming\LWD Technology, Inc\Realm Works -> D:\Realm Works

The only registry key I found is "Computer\HKEY_CURRENT_USER\Software\Lone Wolf Development\Realm Works" and there is value "Install Path" that points to the some temp directory C:\Users\<username>\AppData\Local\Temp\RealmWorks directory with single sync folder... :confused:

Do you know if there will be issues with this approach?

Yes, there will be issues with that approach. But your user directory should be on the fastest drive you have so I think your are going about this backward anyway.

Care to elaborate what kind of issues?

Moving the profile directory cannot be done in supported way post-installation, the hassle is too much and gains are few. Also there are reasons why people should not do that. https://support.microsoft.com/en-us/...rectory-to-a-d

Realm Works already lets you change the Backups folder (the one that, by default, is in your Documents folder) and set how many it keeps. In the Launcher, go to Tools, Manage Database, Automatic Backups.

It just won't work.

You shouldn't move your profile directory off the drive it was created on. You should move that whole drive if you have a faster physical drive, assuming it has the capacity. You fastest drive should always be your boot drive and that should be where your profile goes.

To report the end of this exercise: Realm Works' data folders are moved without re-installation to another drive. Directory junctions are used to make it work. No registry changes are required.
I also had some time to fool around and made App-V package... :D

The overview:

1. Create the new folder structure at the destination drive. RW should be off.
2. Move the each folder via robocopy or cut-paste in Explorer (we assume the permissions on the file system are set properly. If you doubt, robocopy with /COPY:ALL switch will keep them)
3. Create directory junction point as specified above by using command line (mklink /j). This will redirect transparently for the application all read/writes to the other drive.
4. Start RW. Enjoy.

Next challenge is to make it portable without virtualization technologies, but I assume the program is having hard-coded values that will prevent me to enjoy it running from external device without installation. :D

I don't know what won't work, but as I stated above - I intended to move only RW's data files, not my whole profile. :)

Moving the home directory is pointless exercise, as described in the support article, and should be done in very specific cases and with the proper tools. Not in the middle of the life of existing installation.

You're not the first person to try this. Its never gone well. You were warned.

You still don't say why and what went wrong. ;)

Junction points are standard way to provide backward compatibility for applications that are hard coded to look for C:\Documents and Settings, instead of addressing the system variables. What I did was to take care of mechanism that is transparent for RW and move the database and the folder structure in Documents folder.

I was exploring all activity of RW with Sysinternal tools before doing so, and nothing leads me to believe that this will have any problem. I will work with that for week or two, but so far it works just fine.

Searching the forums will show you example of what went wrong ;)

The two threads I found are those:
http://forums.wolflair.com/showthrea...light=Relocate
http://forums.wolflair.com/showthrea...light=Relocate

Today I was doing data uploads, tested exports, imports, sync and other jobs and all workks fine so far. I also moved the temp directory where db log files are and the program is not misbehaving.

Hi there Valyar,

Ryan here, it sounds like you're treading in somewhat unknown waters from what I can tell and I was wondering while you're at it if you'd like the opportunity to catch new BUGs that pertain to the environment should they emerge.

If it's not too much trouble I'd suggest running DbgView whenever possible in this environment to help generate a log file for any errors or strange interactions that may occur as we are uncertain what the long term stability looks like with this kind of installation with the Junction Points.

I suspect you may already have a copy of the latest DbgView but if not you can find one at the following URL.
(https://technet.microsoft.com/en-us/.../bb896647.aspx)
Once you want to login, sync, and work on the realms, run DbgView and if any error occurs, select "File -> Save As..." in DbgView to save the log.

You can send any support requests along with the log files and other relevant details to our general purpose support email address you'll see in my signature.

--
Ryan Furnas
Lone Wolf Development Support - support@wolflair.com
http://www.wolflair.com

Hello Ryan,

Sure thing, I will be capturing the log file while I am using Realm Works on the machine where I did the redirection. So far it works fine, I did export/import, restore and backup operations without any problems. Lets see what the debug will tell.

Since June I completely redirected all RW folders from the system drive to another drive (can be done also to another partition if you have one drive) via the junction points approach. I also added the scratch directory where the sync files are kept and now RW is completely running off another drive. I performed all operations (backup/restore/full sync/export/import) plus heavy usage on the SSD equipped laptop.

Using Junction point you can also prepare the filesystem in advance before installing RW to ensure nothing is to be moved after. I tested this as well.

So, if you want to relocate something from RW to another place, this is viable and tested in time solution. Unless LWD provide a way to move things from the %app% directory, like Fantasy Grounds.

No update since June. the problems people had with this were with updates. Don't declare that this works until an update gets pushed out.

The file system operations are transparent for RW, this software is not Oracle RAC with ASM. An update can introduce new locations on the file system or re-arrange the existing, which is not a problem. Updated binaries are not a problem as well.

Unless they need raw disk access or introduce a filter driver for the filesystem for no obvious reason, this works and will work just fine.

I'm just telling you that others had problems. I hadn't thought they would either.

OK, small update on the experiment with the junctions. With the beta there are no issues as expected, because no data paths are changed. In-place update was fine and all works normally.

Looking forward to the next update to see how it goes. :)

Sorry for the thread necro, but I was searching for a solution to move the Realms database to a different drive/partition. I just moved

C:\Users\myusername\AppData\Roaming\LWD Technology, Inc\Realm Works

to

D:\LWD Technology, Inc\Realm Works

Then I opened a command line in "C:\Users\myusername\AppData\Roaming" and used the following command to create the Junction point:

mklink /j "LWD Technology, Inc" "D:\LWD Technology, Inc"

Window will respond with:

Junction created for LWD Technology, Inc <<===>> D:\LWD Technology, Inc

I've had no issues opening the database and all prior settings and preferences are retained and working.

Database backups and compressing databases works.

In short, I've not come across any issues whatsoever.

I looked at the two threads that Valyar found (none of the naysayers bothered to post a link or describe what issues would be caused by this approach). The first describes someone using the junction point as describe in this thread with no issues mentioned, so it supports this approach. The second just discusses moving backup location. Which is a different issue and you can already set your backup location.

Anyway, follow this advice at your own risk, but junction points seem to work just fine.