Path to configuration files cannot be changed #1612

JKjakay · 2025-01-25T09:59:18Z

Describe the bug
I use the flatpak version of Amiberry (7.0.1) on Fedora Linux 41. I have my Amiga files in a custom directory and would like to put the "Amiberry" folder there, too. So I want to move it out of my home directory. I tried changing the paths settings to ROMs, disks, etc. - and that works beautifully.
But changing the default path to configurations does not work. It will always revert to /home/username/Amiberry/conf/

In addition, I cannot move the "Amiberry" folder out of my home folder. It will be recreated there.

To Reproduce
Steps to reproduce the behavior:

Simply try to change the path to configs. It will seem that everything is ok but when quitting and re-starting Amiberry, the path will be re-set to /home/username/Amiberry/conf/

Expected behavior
I would really like it very much to move the configs (and the whole Amiberry directory) to a custom destination instead of having it clutter my home folder

Love Amiberry? Please consider supporting it:
👉 https://ko-fi.com/midwan

giantclambake · 2025-01-25T10:06:28Z

Do any of these path variables help you? --> https://github.com/BlitterStudio/amiberry/wiki/Amiberry-directories

JKjakay · 2025-01-25T10:15:26Z

I assume you are referring to this:

If an ENV variable named AMIBERRY_CONFIG_DIR is found, and it points to an existing directory, it will be used.
Otherwise, $HOME/Amiberry/conf (or $HOME/Amiberry/Configurations on macOS) will be created and used.
In the unlikely scenario that all the above checks failed, it will use the fallback of expecting it under the current directory + /conf.

So you are saying that despite config paths being present in the Amiberry menu, it cannot be changed there? What's the point of doing this?

giantclambake · 2025-01-25T10:44:37Z

Never assume =)

I test all aspects of amiberry, including the documentation ~ if someone asks a question, and I know a relevant solution is provided on the amiberry Wiki, I will proffer that solution --- this allows us to divine if the documentation can be understood, addresses the question at hand, or else that could do with some improvement.

We have no idea what the user's response might be....ie; could be anywhere from "how do I do that?", to replies such as yours, questioning the sanity of how things operate. Needless to say, we appreciate all feedback ;)

In this case, that's a fair question ~ the way I see it, because $AMIBERRY_CONFIG_DIR may exist, and the logic ends up at $HOME/Amiberry/conf if not found, perhaps the GUI->Paths->Configurations dialog should no longer be included?

Elsewise, it's some bug, and @midwan will have the best answer here =)

midwan · 2025-01-25T11:29:35Z

The logic here is as follows:

when Amiberry starts up, it needs to load the amiberry.conf file, to read all the global settings from it (if it exists). These settings include the path to configurations, as well.
Since that file may not even exist yet (e.g. first installation), it needs to know where to look. Therefore, some defaults are set-up, including a fallback.
These defaults use a few possible scenarios, to decide where the directories and files should exist. The XDG directories are used for instance, but if those special ENV variables are set, they take priority. There is also a check for Portable mode, and if that is detected then everything will be assumed to live under the starting directory (like older versions did).

So you see, it's a bit of a catch-22: You need to load the config file, to know where the config files should be - so where do you look for it? :)

JKjakay · 2025-01-25T12:17:32Z

Ok, I'll just ignore the config path setting in the menu. No matter, I really like Amiberry and I'll probably just switch to portable mode.

JKjakay · 2025-01-25T12:42:36Z

So you see, it's a bit of a catch-22: You need to load the config file, to know where the config files should be - so where do you look for it? :)

Just my 2 cents: You could create a amiberry folder in the .config directory on linux and put amiberry.conf in there. It's what .config is there for, after all. Vice, hatari and many other emulators do it like this. I mean:
"/home/username/.config/amiberry/amiberry.conf"

Keeps everything nice and tidy and still absolutely predictable. You could still create the normal /home/username/Amiberry folder for roms, disks etc. If the user wants to change that, they can do it, could even move the whole Amiberry folder as long as the new paths are entered in the file in .config/amiberry via the menu.

giantclambake · 2025-01-25T12:53:31Z

From the same page I linked ~ https://github.com/BlitterStudio/amiberry/wiki/Amiberry-directories#amiberryconf

JKjakay · 2025-01-25T16:19:25Z

I admire your documentation, but unfortunately it seems to be wrong:

The Application-generated amiberry.conf file, where global Amiberry settings are saved, is no longer placed inside the conf directory. Instead, this will now be placed under $XDG_CONFIG_HOME/amiberry/amiberry.conf (which by default, would translate to ~/.config/amiberry/amiberry.conf)

There is no folder ~/.config/amiberry for me, maybe because I am on flatpak?

What I have is:

~/.var/app/com.blitterstudio.amiberry/data/conf/amiberry.conf
~/.var/app/com.blitterstudio.amiberry/config/amiberry/amiberry.conf

And there seems to be no entry for a config path in it?

midwan · 2025-01-25T18:16:27Z

On Flatpak, the XDG_CONFIG_HOME variable, which Amiberry uses, is set under the application's install path. Which is, ~/.var/app/com.blitterstudio.amiberry/config/, as you found in your case.

If you had it installed globally with one of the packages (i.e. not a Flatpak), then the default would have been what is mentioned in the Wiki. I can update that page to mention the Flatpak case as well, to make it more clear.

Otherwise you're correct, there is no entry for config files anymore. This was removed during the refactoring, as it is now decided on startup, based on the rules mentioned in the Wiki (ENV variable first, otherwise $HOME/Amiberry/conf). Perhaps this can be added back, I didn't think it would cause issues like this. :)

mrandreastoth · 2025-01-25T22:58:51Z

I installed Amiberry from source under EndeavourOS and all user-editable paths except the conf path saves. In fact, all paths, with the exception of conf, has a corresponding entry in the amiberry.conf file. Yes, I have read the documentation and I know about the environment variable for conf, however, if the user interface provides a user-editable property, as it does, then one expects this to work as per the other user-editable properties, but, for some reason the conf property doesn't.

To reproduce...

Run Amiberry
Go to Paths
Change the conf path to a custom path
Exit
Run Amiberry
Go to paths

Expected behaviour...

The conf path equals the custom path.

Actual behaviour...

The conf path has reset.

giantclambake · 2025-01-26T02:24:54Z

@midwan ~ operational semantics aside, you know what I say ...ie;

Paths panel Configurations files: textbox has a '...' selector widget which is ineffectual, as the Configurations path is always reset to default....(you know what I'm like about GUI elements that do aught =) This basically echos what @mrandreastoth says above, which I agree with....it's pointless if it can't/doesn't actually do anything...

That's why (above) I swiftly moved to 'remove Configuration files: from the GUI Paths panel'.... (but ofc I know that puts us at odds with the winuae GUI make-up ;)

I very much didn't consider this specific scenario in detail ~ I had thought users of (linux/macOS) systems would just use the provided packages (.deb .dmg .rpm) ....I didn't really examine ENV_VAR usage too deeply (it's more the purview of custom deployments like AmiKit, Retropie, others)....but ofc works fine on LFS (no package manager, just XDG framework)...

Time to test these ENV_VARs a bit more closely.....

AMIBERRY_HOME_DIR ~ must be set before package installation.
If amiberry is already installed, setting this variable afterwards has no effect. The reason is, if this variable is unset at installation time, then the installation process will create ~/.config/amiberry/amiberry.conf as per normal, and it will contain the default path element ...ie; /home/gcb/Amiberry/{all directories/files}.

Ergo, if you export AMIBERRY_HOME_DIR after installation time, amiberry will source ~/.config/amiberry/amiberry.conf which contains the relative paths present/used at install time, and thus $AMIBERRY_HOME_DIR is not used.

Note: I would have expected $AMIBERRY_HOME_DIR to encapsulate the conf/ directory as well, unless overridden by $AMIBERRY_CONFIG_DIR ...but this is not so - configuration files & retroarcg configs always seem to point to /home/gcb/Amiberry/.

If you subsequently set $AMIBERRY_CONFIG_DIR and start amiberry again, the Configuration files: path is updated in the GUI accordingly, but the retroarch config path still points to /home/gcb/Amiberry/ .... current situation to fix this;

If you set either the AMIBERRY_HOME_DIR or AMIBERRY_CONFIG_DIR variables after amiberry has been installed, you must delete the ~/.config/amiberry/amiberry.conf before restarting amiberry, so it can recreate the amiberry.conf file accordingly.

I couldn't find anything else awry ~ wiki/Amiberry-directories should include documentation as per above para, IMHO.

AMIBERRY_DATA_DIR is not exposed to GUI, and does test correctly AFAICT.

HTH

midwan · 2025-01-26T11:02:37Z

Yes, I agree this needs improvements.

The configs path should be editable, and therefore should have an entry in the amiberry.conf file.
Also, I think the startup logic needs some refactoring. If the amiberry.conf file is found, it should read the contents from there and use those paths before creating the default ones, if not then proceed as it currently does today.

…g the default ones (#1612, #1613) Change the behavior on startup, regarding the default directories. Check for the existence of the amiberry.conf file, and if found, load the settings from there, before attempting to create any missing directories. This should fix the behavior where the default directories were always created, even if you had other paths configured in the conf file. Also, add the config_path back to the amiberry.conf file, which was removed earlier.

midwan · 2025-01-26T11:40:59Z

The above commit should fix this issue. Please confirm when you get a chance.

midwan · 2025-01-26T11:47:44Z

Changes:

Change the behavior on startup, regarding the default directories.
Check for the existence of the amiberry.conf file, and if found, load the settings from there, before attempting to create any missing directories.
This should fix the behavior where the default directories were always created, even if you had other paths configured in the conf file.

Also, add the config_path back to the amiberry.conf file, which was removed earlier.

mrandreastoth · 2025-01-26T14:06:51Z

@midwan, I can't wait to test these changes 👍

mrandreastoth · 2025-01-26T21:57:28Z

@midwan, I've tested your changes and I can report that everything except for one thing works: the conf directory is still created but the conf_path is untouched, as it should be.

How I tested...

I start afresh by deleting ~/Amiberry and $XDG_CONFIG_HOME/amiberry and then I run my script, below, which prepares the home directory. The scripts sets up the folders as well as writes the path key/value pairs to amiberry.conf. I then run Amiberry. It is at this stage that it creates the conf folder under the Amiberry directory. The expected behaviour is that it doesn't because the conf_path is defined in the amiberry.conf file.

My script, "create_home_amiberry.sh"...

#!/bin/bash

# Use AMIBERRY_HOME_DIR if set, otherwise default to $HOME/Amiberry
HOME_OBJ="${AMIBERRY_HOME_DIR:-$HOME/Amiberry}"
CONF_FILE="$XDG_CONFIG_HOME/amiberry/amiberry.conf"
SOURCE_OBJ="/usr/local/share/amiberry"
SOURCE_LIB="/usr/local/lib/amiberry"

mkdir -p "$HOME_OBJ"
cd "$HOME_OBJ"

mkdir -p amiga

cp -rL "$SOURCE_OBJ/roms" amiga/.
#mkdir -p amiga/roms/mt32-roms
#find "$SOURCE_OBJ/amiga/roms/" -maxdepth 1 -type f -exec ln -s {} amiga/roms/ \;
#find "$SOURCE_OBJ/amiga/roms/mt32-roms/" -maxdepth 1 -type f -exec ln -s {} amiga/roms/mt32-roms/ \;

cp -rL "$SOURCE_OBJ/data/floppy_sounds" amiga/.
#mkdir -p amiga/floppy_sounds
#ln -s "$SOURCE_OBJ/amiga/floppy_sounds/*" amiga/floppy_sounds/

cp -rL "$SOURCE_OBJ/controllers" .
cp -rL "/usr/local/lib/amiberry" plugins
#cp -rL "$SOURCE_OBJ/themes" .
cp -rL "$SOURCE_OBJ/media" .
cp -rL "$SOURCE_OBJ/whdboot" .

mkdir -p configurations

mkdir -p save/disk_images
mkdir -p save/disk_rips
mkdir -p save/states
mkdir -p save/nvram
mkdir -p save/screenshots
mkdir -p save/videos
mkdir -p save/input_logs

# Function to check and update or append the key-value pair
update_config() {
    local key="$1"
    local value="$2"

    # If the key exists, update it
    if grep -q "^$key=" "$CONF_FILE"; then
        # Update the value of the existing key
        sed -i "s|^$key=.*|$key=$value|" "$CONF_FILE"
    else
        # Append the key-value pair with a newline before it
        echo -e "\n$key=$value" >> "$CONF_FILE"
    fi

    # Remove any blank lines from the config file
    sed -i '/^$/d' "$CONF_FILE"
}

# Create the amiberry.conf file if it doesn't exist
if [ ! -f "$CONF_FILE" ]; then
    # Create the directory if it doesn't exist
    mkdir -p "$(dirname "$CONF_FILE")"
    touch "$CONF_FILE"
fi

# Update the config file with the key-value pairs
update_config "config_path" "$HOME_OBJ/configurations/"
update_config "controllers_path" "$HOME_OBJ/controllers/"
update_config "retroarch_config" "$XDG_CONFIG_HOME/amiberry/retroarch.cfg"
update_config "whdboot_path" "$HOME_OBJ/whdboot/"
update_config "whdload_arch_path" "$HOME_OBJ/media/floppy_disks/whdload/"
update_config "floppy_path" "$HOME_OBJ/media/floppy_disks/adf/"
update_config "harddrive_path" "$HOME_OBJ/media/hard_disks/"
update_config "cdrom_path" "$HOME_OBJ/media/optical_discs/"
update_config "logfile_path" "$HOME_OBJ/save/amiberry.log"
update_config "rom_path" "$HOME_OBJ/amiga/roms/"
update_config "rp9_path" "$HOME_OBJ/media/floppy_disks/rp9/"
update_config "floppy_sounds_dir" "$HOME_OBJ/amiga/floppy_sounds/"
update_config "saveimage_dir" "$HOME_OBJ/save/disk_images/"
update_config "savestate_dir" "$HOME_OBJ/save/states/"
update_config "screenshot_dir" "$HOME_OBJ/save/screenshots/"
update_config "ripper_path" "$HOME_OBJ/save/disk_rips/"
update_config "inputrecordings_dir" "$HOME_OBJ/save/input_logs/"
update_config "nvram_dir" "$HOME_OBJ/save/nvram/"
update_config "plugins_dir" "$HOME_OBJ/plugins/"
update_config "video_dir" "$HOME_OBJ/save/videos/"
update_config "themes_path" "$HOME_OBJ/themes/"

# Required directories - not uused at this stage
directories=(
    "$HOME_OBJ/configurations"
    "$HOME_OBJ/controllers"
    "$XDG_CONFIG_HOME/amiberry"
    "$HOME_OBJ/media/floppy_disks/whdboot"
    "$HOME_OBJ/media/floppy_disks/whdload"
    "$HOME_OBJ/media/floppy_disks/adf"
    "$HOME_OBJ/media/hard_disks"
    "$HOME_OBJ/media/optical_discs"
    "$XDG_CONFIG_HOME/amiberry"
    "$HOME_OBJ/amiga/roms"
    "$HOME_OBJ/media/floppy_disks/rp9"
    "$HOME_OBJ/amiga/floppy_sounds"
    "$HOME_OBJ/save/disk_images"
    "$HOME_OBJ/save/states"
    "$HOME_OBJ/save/screenshots"
    "$HOME_OBJ/save/disk_rips"
    "$HOME_OBJ/save/input_logs"
    "$HOME_OBJ/save/nvram"
    "$HOME_OBJ/plugins"
    "$HOME_OBJ/save/videos"
    "$HOME_OBJ/themes"
)

# Create the directories - not used at this stage
#for dir in "${directories[@]}"; do
#    mkdir -p "$dir"
#done

# Print a success message
echo "Home Amiberry object created successfully at $HOME_OBJ"

giantclambake · 2025-01-27T01:20:54Z

The above commit should fix this issue. Please confirm when you get a chance.

Both Configuration files: and RetroArch configuration file (ra.cfg): paths are now in sync when AMIBERRY_CONFIG_DIR is set
The Configuration files: selector in the GUI, can now be set independently (irrespective of $AMIBERRY_CONFIG_DIR)
The AMIBERRY_HOME_DIR env_var does work properly ...however....

It is still the case that, after installing amiberry from ie; the .deb ...

If you set either the AMIBERRY_HOME_DIR or AMIBERRY_CONFIG_DIR variables after amiberry has been installed, you must delete the ~/.config/amiberry/amiberry.conf before restarting amiberry, so it can recreate the amiberry.conf file accordingly.

Not sure how you feel about this, but I think that's okay....ie; we are discussing 'custom' changes to the 'standard' installation template, and having to delete the amiberry.conf file after setting these env_vars is ... in my mind at least... a trivial sort of caveat wrt setting up a 'custom' environment like this....

....if I get really pedantic, amiberry should test for the env_vars AMIBERRY_HOME_DIR or AMIBERRY_CONFIG_DIR upon start, and if exists, delete the amiberry.conf file, and create a new one included the altered paths....(seems easier to me just to manually delete amiberry.conf when dealing with env_var overrides)...

Not seeing a lot wrong here now ~ possibly I should check TGZ packaging (or local install), but I believe the same scenario will play-out there as well ;)

HTH

Additional: tested TGZ build and local install ~ as expected, same results ;)

midwan · 2025-01-27T15:39:47Z

@midwan, I've tested your changes and I can report that everything except for one thing works: the conf directory is still created but the conf_path is untouched, as it should be.

How I tested...

I start afresh by deleting ~/Amiberry and $XDG_CONFIG_HOME/amiberry and then I run my script, below, which prepares the home directory. The scripts sets up the folders as well as writes the path key/value pairs to amiberry.conf. I then run Amiberry. It is at this stage that it creates the conf folder under the Amiberry directory. The expected behaviour is that it doesn't because the conf_path is defined in the amiberry.conf file.

You shouldn't really need any scripts to set things up, if you use CMake install correctly.

EDIT: Looking at this closer, I think there's some more improvements that could be made regarding the conf dir generation.

Amiberry/conf was always created on startup, as part of the get_config_directory process. We should be able to skip that at that step, and only create it if it's missing after loading the amiberry.conf file, since the path might be different there.

midwan · 2025-01-27T15:57:24Z

New commit above, hopefully improves this further

giantclambake · 2025-01-28T01:08:22Z

Yeah, I think that's okay now ... at least, AFAICT.... (I don't use flatpaks)

...touching back on operational semantics, wrt AMIBERRY_HOME_DIR or AMIBERRY_CONFIG_DIR variables, I imagine users who need this, would set the env_vars prior to first start, and then everything works swimmingly ~ OTOH, if you wish to set these after first start, you still need rm -fr ~/.config/amiberry in some cases...

Perhaps something should be added to wiki/Amiberry-directories about this?

In any event, 'works for me' would seem to be the case ~ OP should retest (but I guess that's unlikely until you spin-up a new flatpak containing these commits ;)

Note: I didn't actually check AMIBERRY_PLUGINS_DIR as it wasn't in question here =)

mrandreastoth · 2025-01-28T18:35:53Z

@midwan: the reason for the script is for systems installed from a package manager, not those built from source.

midwan · 2025-01-28T20:56:16Z

What kind of package manager?
There are DEB and RPM packages already provided, which should take care of the installation. Are you working on something else? Perhaps it can be integrated with the current options.

giantclambake · 2025-01-28T23:33:16Z

@midwan ~ wrt this ticket, EndeavourOS is being used, which is Arch based. I tested against CachyOS (also Arch based), and not being an Arch user myself, I suppose this ropes in AUR & pacman?

As I'm unsure of that situation, I just used cmake directly....which works fine here. All I can imagine, is there's some confusion regarding an 'uninstall' target, which cmake doesn't provide. (ofc, if one uses a .deb/.rpm package you need 'remove' the currently installed package to avoid the 'package already installed' check...[or else force the install]).

AFAIK, the cmake install target replaces existing installed files, so can be construed as an 'update' path, without need to remove previously installed files?

midwan · 2025-01-29T08:56:17Z

I believe we already have a community-maintained AUR package already, though. Doesn't that work as expected?

In any case, I think this specific case can be closed now, until further notice.

mrandreastoth · 2025-01-29T14:14:30Z

I am using CMake to install. I always delete the installed files manually before an installation. I then test the installation as-is and report on my findings. After this I blow away the files installed into $HOME and run my installation script to test it, but, inadvertently, I have been finding issues with Amiberry, which is how this ticket and some others have come to be.

midwan · 2025-01-29T14:16:58Z

CMake will also install files in XDG_CONFIG_HOME and XDG_DATA_HOME, not just HOME... ;)

solskogen · 2025-01-29T14:36:21Z

CMake will also install files in XDG_CONFIG_HOME and XDG_DATA_HOME, not just HOME... ;)

I don't think it does, but if it does it's wrong.
https://aur.archlinux.org/packages/amiberry-git

midwan · 2025-01-29T15:37:52Z

You're right, it doesn't - Amiberry does, on startup. And that depends on a few things (if portable mode is set, if the special ENV variables are set)

midwan self-assigned this Jan 25, 2025

midwan added the question label Jan 25, 2025

mrandreastoth mentioned this issue Jan 26, 2025

Amiberry insits or creating default directories and theme file even when user-defined paths have been defined #1613

Closed

mrandreastoth mentioned this issue Jan 27, 2025

Updating WHDBooter files fails/local WHDBoot directory never created/populated #1615

Closed

midwan closed this as completed Jan 29, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Path to configuration files cannot be changed #1612

Path to configuration files cannot be changed #1612

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

midwan commented Jan 25, 2025

JKjakay commented Jan 25, 2025

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

JKjakay commented Jan 25, 2025 •

edited

Loading

midwan commented Jan 25, 2025

mrandreastoth commented Jan 25, 2025 •

edited

Loading

giantclambake commented Jan 26, 2025

midwan commented Jan 26, 2025

midwan commented Jan 26, 2025

midwan commented Jan 26, 2025

mrandreastoth commented Jan 26, 2025

mrandreastoth commented Jan 26, 2025

giantclambake commented Jan 27, 2025 •

edited

Loading

midwan commented Jan 27, 2025 •

edited

Loading

midwan commented Jan 27, 2025

giantclambake commented Jan 28, 2025

mrandreastoth commented Jan 28, 2025

midwan commented Jan 28, 2025

giantclambake commented Jan 28, 2025

midwan commented Jan 29, 2025

mrandreastoth commented Jan 29, 2025

midwan commented Jan 29, 2025

solskogen commented Jan 29, 2025

midwan commented Jan 29, 2025

Path to configuration files cannot be changed #1612

Path to configuration files cannot be changed #1612

Comments

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

midwan commented Jan 25, 2025

JKjakay commented Jan 25, 2025

JKjakay commented Jan 25, 2025

giantclambake commented Jan 25, 2025

JKjakay commented Jan 25, 2025 • edited Loading

midwan commented Jan 25, 2025

mrandreastoth commented Jan 25, 2025 • edited Loading

giantclambake commented Jan 26, 2025

midwan commented Jan 26, 2025

midwan commented Jan 26, 2025

midwan commented Jan 26, 2025

mrandreastoth commented Jan 26, 2025

mrandreastoth commented Jan 26, 2025

giantclambake commented Jan 27, 2025 • edited Loading

midwan commented Jan 27, 2025 • edited Loading

midwan commented Jan 27, 2025

giantclambake commented Jan 28, 2025

mrandreastoth commented Jan 28, 2025

midwan commented Jan 28, 2025

giantclambake commented Jan 28, 2025

midwan commented Jan 29, 2025

mrandreastoth commented Jan 29, 2025

midwan commented Jan 29, 2025

solskogen commented Jan 29, 2025

midwan commented Jan 29, 2025

JKjakay commented Jan 25, 2025 •

edited

Loading

mrandreastoth commented Jan 25, 2025 •

edited

Loading

giantclambake commented Jan 27, 2025 •

edited

Loading

midwan commented Jan 27, 2025 •

edited

Loading