Closed n1yn closed 2 weeks ago
I don't think it's a bug. Since the config is only written to if the required parameters are missing, this is very useful when upgrading.
I think it is better to add an environment variable SPF_STRICT_CONFIG
, if it is set to 0
or false
, superfile
should ignore this error and use default values for missing parameters.
As @MrPandir said, the main purpose is to write so that when the version update/setting file is missing, it can be automatically supplemented without causing errors.
This feature is very inconvenient for declarative OS users. Why not put the fix behavior behind a flag or output what fields are missing so users can have some feedback on what options are missing.
Additionally, imho writing to someones dotfiles without prompting them seems like a bad idea in general.
This issue involves several problems and features that need to be addressed:
My pull request (PR) introduces a flag that writes default values to any missing entries in the hotkeys configuration instead of doing it every time Superfile is launched. Additionally, it logs each missing entry whenever a user runs Superfile. However, I’m not entirely satisfied with this approach. It was the minimum change required to maintain the ability to write defaults to the config while avoiding automatic modifications at each launch and adding feedback. This breaks automatic config updates when Superfile updates. I don't think this will suffice.
I propose two new actions: validate-hotkeys
and fix-hotkeys
, which would handle validation and correction respectively. I suggest that defaults should be automatically assumed for any missing entries within the hotkeys config, as this is likely what users would expect.
As far as upgrades are concerned, the upgrade feature can call fix-hotkeys to add the missing properties automatically and a config entry can be added to disable the functionality if desired resolving the immutable OS problem. If the primary function of automatically writing the defaults to the config is to gracefully handle updates it's reasonable to say that writing to the config should be done explicitly during an update and not after every launch. This approach would also give people who don't use the built in update approach the ability to update their configs.
@Buttars This is not the best way to do.But I think it's good enough for now. I would close this. feel free to reopen if you have any new good idea. And thank you so much for your contribution!
Description: When running
superfile
in the terminal there's an error message sayingError writing config file: open /home/user/.config/superfile/config.toml: read-only file system
. I usehome-manager
to manage my dotfiles, including superfile. This creates a symlink from the nix store to the config file location (read-only). To my understanding reading the config file should not require it to be writable.Steps to reproduce the behavior:
Expected behavior: Launching normally without requiring to write to the config file on start
System information:
Thanks for reading through this and kudos for the amazing file manager