[Problem] When ran in a directory without write access, MPF.Check will not create a config in the known-good location #887

New Issue

claunia · 2026-01-29T16:23:56Z

claunia commented

2026-01-29 16:23:56 +00:00

Originally created by @InternalLoss on GitHub (Jan 16, 2026).

Originally assigned to: @mnadareski on GitHub.

Before You Submit

Remember to try the latest WIP build to see if the issue has already been addressed.
Is it copy protection related? If so, report the issue here instead.
Check multiple discs to help narrow down the issue
Check the Options to see if changing any of those affects your issue.

If all of those fail, then continue...

Version
What version are you using?

Stable release 3.6.0
WIP release (version here)

Build
What runtime version are you using?

.NET 10 running on macOS 26.3

Describe the issue
When MPF.Check is placed in a read-only directory (such as /usr/local/bin), it does not create a config.json at ~/.config/mpf/config.json as expected.

Furthermore, if a config.json is manually generated and placed either in the same directory as the executable or in the shared configuration directory with just a RedumpUsername/RedumpPassword, the Redump credentials are not used.

To Reproduce

Place MPF.Check binary in /usr/local/bin or similar on-PATH but not writable directory.
Run MPF.Check (I specifically ran MPF.Check xbone xxx.log
Observe no config.json is created in the ~/.config/mpf/ folder
Place a config.json (see below for my example) in ~/.config/mpf/
Run MPF.Check again
Observe the Redump credentials are not used - no Options will be loaded from found configuration file! is shown.

{
"RedumpUsername": "Billy",
"RedumpPassword": "hunter2"
}

Expected behavior

MPF creates a config.json in the ~/.config/mpf/ folder, if it can't write locally.
MPF uses the Redump credentials if only those two variables are set.

Additional context
I also noticed that the config.json made when MPF.Check is running in a directory that's writeable (such as ~/Downloads/) is blank.

Originally created by @InternalLoss on GitHub (Jan 16, 2026). Originally assigned to: @mnadareski on GitHub. **Before You Submit** - Remember to try the [latest WIP build](https://github.com/SabreTools/MPF/releases/tag/rolling) to see if the issue has already been addressed. - Is it copy protection related? If so, report the issue [here](https://github.com/SabreTools/BinaryObjectScanner/issues) instead. - Check multiple discs to help narrow down the issue - Check the Options to see if changing any of those affects your issue. If all of those fail, then continue... **Version** What version are you using? - [x] Stable release 3.6.0 - [ ] WIP release (version here) **Build** What runtime version are you using? - [x] .NET 10 running on macOS 26.3 **Describe the issue** When MPF.Check is placed in a read-only directory (such as `/usr/local/bin`), it does not create a config.json at `~/.config/mpf/config.json` as expected. Furthermore, if a config.json is manually generated and placed either in the same directory as the executable or in the shared configuration directory with *just* a RedumpUsername/RedumpPassword, the Redump credentials are not used. **To Reproduce** 1. Place `MPF.Check` binary in `/usr/local/bin` or similar on-PATH but not writable directory. 2. Run `MPF.Check` (I specifically ran `MPF.Check xbone xxx.log` 3. Observe no config.json is created in the ~/.config/mpf/ folder 4. Place a config.json (see below for my example) in ~/.config/mpf/ 5. Run MPF.Check again 6. Observe the Redump credentials are not used - no `Options will be loaded from found configuration file!` is shown. ```json { "RedumpUsername": "Billy", "RedumpPassword": "hunter2" } ``` **Expected behavior** 1. MPF creates a config.json in the ~/.config/mpf/ folder, if it can't write locally. 2. MPF uses the Redump credentials if only those two variables are set. **Additional context** I also noticed that the config.json made when MPF.Check is running in a directory that's writeable (such as ~/Downloads/) is blank.

claunia added the bug label 2026-01-29 16:23:56 +00:00

claunia commented

2026-01-29 16:23:57 +00:00

@mnadareski commented on GitHub (Jan 16, 2026):

For the part of the issue regarding partial configs is very much expected. The configuration files are not expected to be partial as they are generated by both MPF.UI and MPF.CLI. One of the configuration items, FirstRun, is used as an indicator for a lot of stuff to ensure new users have a different experience. I do not currently consider adding support for partial configs as something I would like to support.

The remainder of the issue is valid and will be investigated when there is time.

@mnadareski commented on GitHub (Jan 16, 2026): For the part of the issue regarding partial configs is very much expected. The configuration files are not expected to be partial as they are generated by both MPF.UI and MPF.CLI. One of the configuration items, `FirstRun`, is used as an indicator for a lot of stuff to ensure new users have a different experience. I do not currently consider adding support for partial configs as something I would like to support. The remainder of the issue is valid and will be investigated when there is time.

claunia commented

2026-01-29 16:23:57 +00:00

@mnadareski commented on GitHub (Jan 16, 2026):

According to a StackOverflow post, the location for configuration files should be in ~/Library/Application Support/<appname>/<appname>.cfg. This is a significant departure from the current OS-agnostic setup and may mean that Windows changes to %APPDATA% in the process as well. I was hoping to avoid this, to be entirely honest.

Addendum: This enforcement of directory rules may also explain the blank configuration file being generated. I have no idea how, but this may mean that macOS will always require a centralized configuration file.

@mnadareski commented on GitHub (Jan 16, 2026): According to a [StackOverflow post](https://stackoverflow.com/questions/15677388/default-location-for-configuration-files-macos), the location for configuration files should be in `~/Library/Application Support/<appname>/<appname>.cfg`. This is a significant departure from the current OS-agnostic setup and may mean that Windows changes to `%APPDATA%` in the process as well. I was hoping to avoid this, to be entirely honest. Addendum: This enforcement of directory rules may also explain the blank configuration file being generated. I have no idea how, but this may mean that macOS will always require a centralized configuration file.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#887