Bug 498694

Summary:	Saving settings overwrites symlink with regular file
Product:	[Applications] systemsettings	Reporter:	Rua <ruawhitepaw>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	kde
Priority:	NOR
Version First Reported In:	6.2.5
Target Milestone:	---
Platform:	NixOS
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Rua 2025-01-15 14:53:53 UTC

SUMMARY
When saving settings, if a file that needs to be saved is a symlink, then the symlink is replaced with a regular file.

STEPS TO REPRODUCE
1. Rename `~/.config/fontconfig/conf.d/10-hm-fonts.conf` to something else.
2. Create a symlink named `10-hm-fonts.conf` that points to the above renamed file.
3. Open System Settings.
4. Go to the Text & Fonts settings tab.
5. Choose a different font, size or style for one of the options, then apply.

OBSERVED RESULT
`10-hm-fonts.conf` is now a regular file, no longer a symlink.

EXPECTED RESULT
The file should remain a symlink, and the destination for the new symlink should be determined by following the chain of symlinks to the final file.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: NixOS 24.11
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0

ADDITIONAL INFORMATION
This bug has already been reported for home-manager: https://github.com/nix-community/home-manager/issues/5162
I have only confirmed it with the file mentioned above, but others have encountered it with other files too.

For context: Home-manager is a program for managing certain aspects of one's home directory, and is based on the Nix package manager. As with Nix more generally, files that are managed by home-manager are created in a separate Nix store location, and are then symlinked from their usual locations to the store. The in-store files are read-only and are not intended to be modified, so in this situation, System Settings should just skip trying to save the file since home-manager is managing it internally.

Comment 1 David Edmundson 2025-01-15 15:43:41 UTC

>The file should remain a symlink, and the destination for the new symlink should be determined by following the chain of symlinks to the final file.

We're not doing that. I get that it will fix your bug, but there's a myriad of new challenges and there's a limit in what features we should support for code maintenance. 
Ultimately from a system settings POV we're managing the file and clearing up whatever else the user has left in the way. 

If you guys want to patch it in Nix:
 - kxftconfig.cpp in  where m_file is created wrap it in 
QFile::filesystemSymLinkTarget