Page 1 of 1

Move configfile sabnzbd.ini permanently

Posted: March 2nd, 2012, 4:29 pm
by spyvingen
Would be good to be able to use a command that changes the config file path permanently so you dont have to worry about that anymore in the future when formating and so on.

Re: Move configfile sabnzbd.ini permanently

Posted: March 2nd, 2012, 4:42 pm
by jcfp
Already possible. Stop the program, move the ini file, run the program again using the -f <full path to ini file> command line option. If you have shortcuts, modify those to include the option.

Re: Move configfile sabnzbd.ini permanently

Posted: March 3rd, 2012, 7:18 am
by spyvingen
Thts what ive done but it would be better of if you could just change it permanently. Even better would be a path feild in the config gui, cus i dont think anybody want the settings to disapear when formating.

Would'nt it be better if the config file is default in the sabnzb dir, if it is you can just install it on like d: and then never have to worry about settings.

Re: Move configfile sabnzbd.ini permanently

Posted: March 3rd, 2012, 8:58 am
by jcfp
spyvingen wrote:Even better would be a path feild in the config gui, cus i dont think anybody want the settings to disapear when formating.
That's what proper backups are for; begin forgetful when formatting isn't the only way to loose your stuff (hardware failure!). A field in the config is not feasible, since the program would have to store that setting somewhere. Subsequently, in order to read the setting, it must already know the location of a config file, making such a setting useless to begin with.
spyvingen wrote:Would'nt it be better if the config file is default in the sabnzb dir, if it is you can just install it on like d: and then never have to worry about settings.
While I'm not a dev, it is common practice in most operating systems (linux/unix/bsd/osx) to keep settings in a (standardized) separate location, and even windows is moving away from its nasty habit of dumping program settings in the install directory. If only because it prevents implementing proper security practices (such as preventing changes by non-admin users to installed programs), as well as having different settings per user account.