Move hydrus db to another folder

[olloff]

Hi,
is it possible to move hydrus db to another location?

I tried to add symlinks to %appdata%\Local\VirtualStore\Program Files\Hydrus Network but client failed to start with following error:

[ScoreUnder]

Can you show what symlink you made and what its target is?

On my linux system I made a symlink from hydrus/db to a directory (which already exists - that is important to note) on another disk. It's working great for me, so I think there should be a way to get it working for you.

[olloff]

Sorry, I must clarify this earlier.

Currently using Windows 10 Insider Preview build 10586.11 to run Hydrus Network version 182. I didn't check Hydrus under linux mainly because I'm too lazy to reboot, but I do so if it helps.
My problem can be OS-related though I already used same technique to move almost all other software to separate partition and never got similar problem.

I tried both NTFS junctions and symlinks (output below) with no difference.

dir "C:\Users\Olloff\AppData\Local\VirtualStore\Program Files"
Volume in drive C is WIN
Volume Serial Number is B2DA-2F5C

Directory of C:\Users\Olloff\AppData\Local\VirtualStore\Program Files

22.11.2015  09:19    <DIR>          .
22.11.2015  09:19    <DIR>          ..
22.11.2015  09:19    <SYMLINKD>     Hydrus Network [F:\.hydrus]
               0 File(s)              0 bytes
               3 Dir(s)   7 408 910 336 bytes free

[ScoreUnder]

The screenshot in the client above is mentioning paths inside C:\Program Files, but your path there is within your user's AppData directory. I'm no longer very up-to-date with how Windows works so I don't know if there's any "magic" going on here, but are you launching Hydrus from the right place? It look like it might be being launched from Program Files, but that's not the place you've symlinked it in.

Also, as for rebooting into linux - IMO it should be the other way around ;) I used to have Windows as my main and boot Ubuntu occasionally, then I tried it the other way around and eventually never booted into Windows again.

[olloff]

The screenshot in the client above is mentioning paths inside C:\Program Files, but your path there is within your user's AppData directory

%appdata%\Local\VirtualStore is part of Windows API - Windows way to treat with programs demanding access to user-prohibited folders such as Program Files. I believe its just a junction point between %programfiles%<program_folder> and %appdata%\Local\VirtualStore\Program Files<program_folder> where all files created by unprivileged users are stored.

are you launching Hydrus from the right place

Too right. Hydrus client is correctly installed to Program Files but I was sure it stores ./db as user files, as recomended since Windows XP and using VirtualStore is intended. Its still strange why Hydrus can't resolve paths beneath VirtualStore, but I moved installed files to C:\Hydrus and it works well. Thanks, your message helped me connect all the dots.

Should I do a separate feature request issue? I believe Hydrus should give an option to move db and log folders to other location.
Also it should respect Windows admin policy and store db and log as user files where even unprivileged user can reach them. This shouldn't be applied to the application files, only db itself.
At least these practices should be discussed.

[hydrusnetwork]

Thank you for your comments. I apologise for only being able to get around to them now.

At the moment, hydrus is designed to be always in portable mode, so that all its database, files and settings are tucked inside the installation directory for easy backup and general access. I do not put anything in AppData, in part to better support running multiple instances of the program and also to keep things simple for the different platform releases. Running under Program Files or another protected directory will not work unless you run the program as Admin. C:\hydrus is a great location.

I recently added the ability to move the client_files portion of the database to other external locations, although this was aimed at people with huge collections too large to store on any one hard drive or who wanted to store files on an hdd but the .db file on an ssd.

I am not sure if I will support moving all the editable files to AppData or some other user directory. What's the benefit?

[olloff]

I recently added the ability to move the client_files portion of the database to other external locations

I just tried the most recent version and must to say its very convenient way to deal with growing db. Thank you!

Can you please be more specific how weight setting works? Sorry if my questions would be too obvious to you:
Say if I have an db with client_files on a two different external drives (hypothetically speaking) with different weights, would both of them be present and readable in hydrus simultaneously?
What happens if I detach one external drive? Will it delete my files from db upon maintenance? What happens if I detach external drive when hydrus client is running?

[AreFinstad]

agreeing with olloff here, we need tooltips on new things..... well most things TBH as you keep have to look at your guide site to learn about the program and we cant really learn as we go from within the program with tooltips.
if not tooltips then atleast have a questionmark button next to things to opens the page where you cover this in your guide site.

[Link-Satonaka]

@hydrusnetwork

I am not sure if I will support moving all the editable files to AppData or some other user directory. What's the benefit?

I want to make a package for hydrus in the chocolatey package manager. There is no reason to require admin privileges to "install" hydrus through chocolatey, since you provide a portable package. However, the portable package ends up in an area the User probably won't have full R/W access to- so a chocolatey package can only be made for your installer. If I were able to overcome the permission issues with portable hydrus in chocolatey, the DB would still be in chocolatey's installdir and the deletion of Chocolatey should NOT mean the loss of user files. On the other hand, an installer means there can be only one instance of hydrus deployed through chocolatey.

Now consider the location of the DB folder- Linux is built around the notion that user files should NEVER be found outside the /home directory, which is why the archlinux hydrus package (https://aur.archlinux.org/packages/hydrus/) has been patched to place the DB folder in the user's $HOME. Windows recovery is built around the principle that all user files are in the C:\Users folder- with the Hydrus installer, pictures end up in C:\Hydrus, which is easy to lose in recovery scenarios.

If you don't plan on supporting different locations for db, then you should probably stop releasing installers for Windows. Otherwise, you should start polling users for their preference: %appdata%\Roaming\hydrus\db or %USERPROFILE%\Pictures\hydrus\db. I vote for Pictures folder, to minimize the risk of accidental deletion when migrating/backing up. The portable release should still keep it's database local/portable. The installer then should be putting hydrus itself into Program Files.

I propose you take this opportunity to implement support for multiple databases from one instance of Hydrus client. If the user has set up multiple databases, then when Hydrus starts it should ask you which database you would like to boot into: the default, or the one under Z:\private\hydrus\db. It goes without saying then, that you need to have "add existing database" and "create new database" buttons into this prompt.