https://bugs.kde.org/show_bug.cgi?id=525445
Bug ID: 525445
Summary: kcm_fontinst unconditionally replaces symlinked
fontconfig files with plain-file copies on every start
Classification: Applications
Product: systemsettings
Version First 6.6.6
Reported In:
Platform: NixOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: kcm_fontinst
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
Split off from bug 525304 at TraceyC's request (comment there), to isolate the
file-rewriting behaviour from the separate kcm_fontinst crash question.
Every time the Fonts KCM is opened (System Settings -> Appearance & Style ->
Fonts), it D-Bus-activates `org.kde.fontinst`, which rewrites every file under
`~/.config/fontconfig/conf.d/` as a plain-file copy of its current content --
unconditionally, on every single activation, regardless of whether anything
actually changed.
If any of those paths was a symlink (rather than a regular file), fontinst
replaces the symlink itself with a plain file containing a copy of the
symlink's target content. The symlink is gone after this; it does not get
recreated.
This is disruptive for any tool that manages `~/.config/fontconfig/`
declaratively via symlinks -- e.g. Nix Home Manager's `fonts.fontconfig`
module, GNU Stow, or similar dotfile managers. Their usual invariant is: "the
path is either our symlink, or something else entirely wrong has happened."
fontinst's copy-on-every-start behaviour breaks that invariant on every KDE
session that opens the Fonts panel, even when the user made no font changes at
all.
Concretely, for Home Manager on NixOS: every rebuild generates a fresh file at
that path and symlinks it in. The next time fontinst runs, it silently replaces
that symlink with a plain copy. The *next* rebuild after that then finds a
plain file occupying the target path instead of a symlink, differing
byte-for-byte from the freshly generated content (it embeds a new store-path
hash each rebuild), and Home Manager's activation hard-fails with "Existing
file ... would be clobbered" until the file is removed by hand.
I've already worked around this on the Home Manager side: PR
https://github.com/nix-community/home-manager/pull/9920 makes the
`fonts.fontconfig` module force-overwrite its own namespaced files on
activation, so Home Manager no longer hard-fails when fontinst has clobbered a
symlink (open as of this writing, not yet merged). That fixes the
crash-on-rebuild symptom on my end, but it's a workaround on the consumer side
-- it doesn't stop fontinst from destroying the symlink in the first place, so
any tool without an equivalent force-overwrite escape hatch would still hit
this.
STEPS TO REPRODUCE
1. Have `~/.config/fontconfig/conf.d/` contain at least one symlink pointing
elsewhere (e.g. into a Nix store path, or any dotfile-manager-created symlink).
2. Open System Settings -> Appearance & Style -> Fonts (or otherwise trigger
D-Bus activation of `org.kde.fontinst`), without changing any font
configuration.
3. Inspect the files under `~/.config/fontconfig/conf.d/` again.
OBSERVED RESULT
The previously-symlinked files are now plain files containing a copy of what
the symlink pointed to. This happens even when nothing about the font
configuration was changed, and on every single activation of the panel/service.
EXPECTED RESULT
fontinst should not touch a config file it did not need to change -- at
minimum, it should not unconditionally replace a symlink with a plain copy when
the symlink's target content is already correct and nothing about the font set
changed. If fontinst genuinely needs write-ownership of these paths, that's a
reasonable design choice, but it should be documented, and ideally
opt-in/detectable rather than a silent, unconditional rewrite on every panel
open.
SOFTWARE/OS VERSIONS
Same as bug 525304
Operating System: NixOS 26.05
KDE Plasma Version: 6.6.6
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
Windowing System: Wayland
ADDITIONAL INFORMATION
This report only covers the file-rewriting behaviour. The separate question of
the panel's non-deterministic crash (exit 255) remains on 525304, per TraceyC's
request to keep the two issues apart.
--
You are receiving this mail because:
You are watching all bug changes.
