Feature: Set home folder

[mojimba]

Even when specifying a global configuration from in a different location, the util still defaults the home folder to the user profile location (for logging and storage definition files).

I'm not familiar with Go, but if I'm reading this correctly, you're using go-homedir to read this, and I think there's an issue with a "feature" it has to override the home directory with an environment variable (set to "HOME" in Windows). No matter what I've tried so far, this doesn't seem to work...

Ideally if we can get a "-gf" parameter in duplicacy-util itself to set the global folder (bypassing the go-homedir function call), then any logging and storage configuration files could use that?

Thanks!

[jeffaco]

I'm fine adding a flag on where to grab these settings from. But that's just a subset of what is in the global configuration file. The global configuration file is also used for setting up theemail* parameters (there's about a half dozen of those). While I could add parameters for each of these as well, that's painful. Note that I had briefly considered this: If you really didn't want your settings directory to be ~/.duplicacy-util, then you can override that, but it's from a non-hidden file (which was kind of "less optimal"). In that case, I like the idea of -gf.

Lets work backwards a little. Are you complaining because functionally, you don't believe the home directory should be set (although it's set in the processing running Go, so it doesn't change your current process at all)? Or are you actually experiencing a problem? Or is this simply that you really don't want files in your home directory (either the global file or the ~/.duplicacy-util directory)?

If you're experiencing a problem, I'd like to understand that so I can try to address that. What, exactly, is happening? Can you post logs? Can I do something to replicate it on my side?

Thanks!

[mojimba]

The root "problem" (if you like) is that I didn't want to have configuration files all over the place. I have all my duplicacy repositories (and therefore settings files) on various PCs defined in a consistent C:\Backups folder - and I use symbolic links to "pull" in whichever actual folders I want backed up.

C:\Backups currently includes other utility files, like some simple BAT scripts I have to trigger everything, as well as a log folder etc.

Being able to have everything in the same place, including the duplicacy-util home folder (along with the log subfolder, lock file, global and local configs, etc) would be ideal.

In the go-homedir library, for Windows at least, I think it's supposed to return the value of the "HOME" environment variable before attempting anything else:

func dirWindows() (string, error) {
	// First prefer the HOME environmental variable
	if home := os.Getenv("HOME"); home != "" {
		return home, nil
	}
...

However, this does not seem to work for me as a way to override what duplicacy-util is using. I have a BAT file which looks like:

SET HOME=V:\BackupTests
duplicacy-util -f test -b
pause

Although the global config does seem to come from the folder set in the HOME environment variable, it still seems to be looking for the config and other files in the default USERPROFILE location:

02:43:13 Using global config: V:\BackupTests\duplicacy-util.yaml
Error: Config File "test" Not Found in "[C:\\Users\\user1\\.duplicacy-util]"

In the above test I moved the working .duplicacy-util directory along with all the config files into V:\BackupTests\.duplicacy-util

I guess this is by design, hence why I requested the ability to tell duplicacy-util where the home folder (along with all config files) should be.

[jeffaco]

@mojimba Okay, I took a look at this, and I've enhanced capabilities in commit d5e4b88. Not allowing $HOME to be overridden was an oversight on my part, but I felt it was useful to add formal functionality for this.

The commit adds a new -sd qualifier, which lets you specify where the files are actually stored. See the README.md file for details, but the gist is (from the README.md):

---

By default, dupliacy-util stores all files in its storage directory, which is
$HOME/.duplicacy-util by default. Note that, in this document, $HOME refers
to the users home directory (~/ on Mac OS/X and Linux, or /Users/<username>
on Windows).

The storage directory is determined in a variety of ways:

1. First and foremost, if the -sd parameter is specified, this will define
   the location of the storage directory, and duplicacy-util files will be stored
   directly in this directory. In this way, the directory where duplicacy-util stores
   its files could be called anything.

2. If -sd is not specified on the command line, then the value of environment
   variable "$HOME" will be evaluated and will be used as a location to look for
   directory .duplicacy-util.

3. If environment variable "$HOME" is unmodified (or not normally defined on your
   system), then it is expected that directory .duplicacy-util exists in the users
   home directory.

---

This change is in mainline. To pick it up, you'd need to build yourself. Let me know if you need me to publish a release from that.

Note that looking up the global configuration file was not clear from documentation. But if you specified the -g parameter (to specify the global configuration filename), that's not just the filename you were specifying, but the full path. As such, you could have specified this (to a location of your choosing), and that should have allowed you to override directories for everything else. But that's a round about way of doing what you wanted, which is why I added the -sd option.

Let me know if you have any questions, concerns, or problems. Hope this was helpful.

[mojimba]

Great news! I've set up go on a VM and have built a binary - so I think I'm all set.

Thanks!