You’re right, and that’s what I also guessed. In the best case you control the entire file. (Though, I’m wondering if you only talk about servers or also desktop machines.)
Irrelevant User Changes
My specific use case is a desktop application that writes its settings into ~/.config/appname.conf
. For some reason, the configuration file includes things like the plugins that the application uses and the window size and position.
The latter certainly changes every time the user moves the application window or changes its size. Why the heck should I care about taking control over that?!?
– This seems like a valid use case for leaving users freedom, for ignoring ever-changing values. And yak, it does make sense that the application overwrites those changes every time.
When Applications Can’t Handle It
The main problem here is really that the configuration file becomes read-only and it depends on the application whether it can deal with that. In the case of Paperwork, this results in the application being unable to start up. This is certainly an application design issue, but it’s happening and it’s not easy to fix without the application maintainer’s collaboration.
$ paperwork-gtk
[INFO ] [openpaperwork_core.config ] Loading configuration for paperwork2
[INFO ] [openpaperwork_core.config.backend.configparser] Loading configuration 'file:///home/peter/.config/paperwork2.conf' ...
[INFO ] [openpaperwork_core.config.backend.configparser] Writing configuration 'file:///home/peter/.config/paperwork2.conf' ...
[ERROR ] [openpaperwork_core.logs.print ] === UNCAUGHT EXCEPTION ===
Traceback (most recent call last):
File "/nix/store/05d6yqh6z3qpg2l75w0a1xll6d9phibj-paperwork-2.2.5/bin/.paperwork-gtk-wrapped", line 9, in <module>
sys.exit(main())
^^^^^^
...
File "/nix/store/xl8wvki47jl7700hz2i714psqdv3789h-python3.12-openpaperwork-core-2.2.5/lib/python3.12/site-packages/openpaperwork_core/config/backend/configparser.py", line 257, in config_backend_save
with self.core.call_success("fs_open", config_path, 'w') as fd:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/xl8wvki47jl7700hz2i714psqdv3789h-python3.12-openpaperwork-core-2.2.5/lib/python3.12/site-packages/openpaperwork_core/__init__.py", line 503, in call_success
r = callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/xl8wvki47jl7700hz2i714psqdv3789h-python3.12-openpaperwork-core-2.2.5/lib/python3.12/site-packages/openpaperwork_core/fs/python.py", line 38, in fs_open
return codecs.open(path, mode, encoding='utf-8')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen codecs>", line 918, in open
OSError: [Errno 30] Read-only file system: '/home/peter/.config/paperwork2.conf'
[ERROR ] [openpaperwork_core.logs.print ] ==========================
Alternative Solution
This problem is easier to handle when the configuration items are written separately, e.g. when there is not a monolithic file being used but a registry of configuration items like dconf (I already suggested that change).
I hope it’s easier to see now, why enforcing a single configuration item makes sense—or is unfurtunately needed.