Mac - Default Folder Locations

[StusBrainDump]

Hi, so I have Amiberry in my default Applications folder. Amiberry created a set of folders in a username/Documents/Amiberry folder.

How can I move this Amiberry folder up a level to username/Amiberry and not have anything in the Documents folder.

Reason for asking is everything I've read says the amiberry.conf file is read by Amiberry on startup from username/Documents/Amiberry/Configurations/Amiberry.conf. So its a bit of a catch 22 situation (need to find this file within Documents to then read paths for everything else)

Thanks.

[StusBrainDump]

Solved it myself ... sniffing around inside the mac app package I just modified the Contents/Resources/Configuration/amiberry-osx.conf file to remove all the Documents references from the paths so it was just USERNAME/Amiberry/..... When I loaded Amiberry it then found my all my configuration from username/Amiberry

[midwan]

Thanks for sharing the solution that worked for you! )

[StusBrainDump]

Actually, this doesn't solve the problem :(

Although it finds all my configurations in username/Amiberry/Configurations, it still creates an Amiberry folder in username/Documents :(

So it seems on launch, it checks if a username/Documents/Amiberry exists. If it does, just use it. If it doesn't, copy the contents of Amiberry.app/Contents/Resources/ into username/Document/Amiberry.

Then, in my instance, Amiberry loads, reads the config from username/Document/Amiberry, which then points it to the folders in username/Amiberry.

I just want to tell Amiberry where I want my Amiberry folder located and not NEED it to be in username/Documents

[giantclambake]

There's a hardcoded path in src/osdep/amiberry.cpp at Line 3967...

#ifdef __MACH__
	// MacOS stores these files under the user Documents/Amiberry folder
	const std::string macos_home_directory = getenv("HOME");
	const std::string macos_amiberry_directory = macos_home_directory + "/Documents/Amiberry";
	if (!my_existsdir(macos_amiberry_directory.c_str()))
	{
		// Amiberry home dir is missing, generate it and all directories under it
		init_macos_amiberry_folders(macos_amiberry_directory);
		macos_copy_amiberry_files_to_userdir(macos_amiberry_directory);
	}

....from what I can gather, macos_init_amiberry.zsh is also involved...

for file in $CWD_VAR/../Resources/Configurations/**/*(.); do
        if [[ "$file" != "$CWD_VAR/../Resources/Configurations/amiberry-osx.conf" ]]; then
                if [[ "$file" != "$CWD_VAR/../Resources/Configurations/amiberry.conf" ]]; then
                        if [[ ! -f "$USERDIR/Documents/Amiberry/Configurations${file##*/Configurations}" ]]; then
                                echo "Copying $file to $USERDIR/Documents/Amiberry/Configurations${file##*/Configurations}"
                                mkdir -p $(dirname "$USERDIR/Documents/Amiberry/Configurations${file##*/Configurations}")
                                cp $file "$USERDIR/Documents/Amiberry/Configurations${file##*/Configurations}"
                        fi
                fi
        fi
done

I haven't touched MacOS in 2 decades (not about to do it again ;), and I don't know if the variable $EXTERNAL_FILES_DIR actually works in the MacOS case..... but this is where the behavior is coming from.

HTH

[midwan]

Yeah, these paths are currently hardcoded, and the script mentioned takes care of creating and copying the files there if the path doesn't exist. Could be better, but then again nobody complained about it until now :)

[StusBrainDump]

Haha :)

I believe "normal" Mac convention is to store configuration data in a folder under username/Library/Application Support/Appname
So username/Library/Application Support/Amiberry

If the amiberry.conf was copied to here and this was the "live" version that Amiberry looked for then that solves the problem.

That amiberry.config could still by default point to a set of folders in username/Documents/Amiberry, but could then easily be reconfigured by the user to point somewhere else, as they already can.

Basically, move the amiberry.conf file from username/Documents/Amiberry/Configuration/Amiberry.conf to username/Library/Application Support/Amiberry/Amiberry.conf :)

[midwan]

Should be fixed after the new commits now

[StusBrainDump]

Hi @midwan

Tried the latest commit of 5.7.4 (2024-06-27) and it doesn't entirely work as I'd thought it would.
It does indeed look for an amiberry.conf file in username/Library/Application Support/Amiberry/ at startup and does have the correct paths from that amiberry.conf in the UI. And it correctly finds all the content located in those paths which are in my username/Amiberry folder (not in my Documents folder).

However, it seems to still create an Amiberry folder structure under username/Documents/Amiberry regardless, which in my instance isn't needed as my amiberry.conf points to my correct Amiberry folder, username/Amiberry. In fact if I delete everything from the Amiberry folder it's created in username/Documents so it's basically an Amiberry folder with nothing in it, it doesn't recreate the whole structure and still works.

So, no Amiberry folder in username/Documents, the whole folder structure is created at launch. An empty Amiberry folder in username/Documents at launch, it doesn't re-populate it with all the subfolders.

In both scenarios, amiberry.conf is correctly found in username/Library/Application Support/Amiberry, all paths from that file are correct in the UI, and it all works. It just seems to insist on an Amiberry folder existing below the Documents folder.

[midwan]

I must have overlooked that, there's a script that runs on startup and it makes sure that folder structure exists, as it was relying on that to have the content copied in it (on the first launch). I'll take another look at it when I get a chance.