Add option to replace existing files

[justinlovinger]

Having Home Manager fail if an existing file exists is a big foot-gun. As a veteran user, I know what it means when the Home Manager service fails. I know to delete the offending file and reactive the service.

However, I have seen new users struggle with broken configurations, unsure why their Home Manager changes are not realized. Worse, this allows NixOS to update with Home Manager, potentially breaking systems. Worse still, if an existing file exists, users cannot cleanly roll back to previous NixOS generations because Home Manager will fail to realize those previous generations. In the worst case, this can result in an unusable machine with no way to roll back, requiring recovery from a bootable USB.

P.S. This is not a one-off issue. Some applications will override files managed by Home Manager, resulting in this error cropping up repeatedly, even if backupFileExtension is set.

[ncfavier]

You can set home.file."foo/bar".force = true; to replace existing files. Maybe this option should be made visible in the manual.

[justinlovinger]

home.file."foo/bar".force = true; solves the issue for individual files, but not for Home Manager as a whole. An option on the Home Manager module, alongside where backupFileExtension is defined, could solve it more generally.

I also suggest mentioning this option in error messages about existing files. Once a user is informed Home Manager can replace their files, they can back up whatever they want, enable the option, and never have to deal with it again.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[sg-qwt]

force

https://nix-community.github.io/home-manager/options.xhtml#opt-home.file._name_.text Is there any reason why force option is not documented here?

[sg-qwt]

@rycee the force option is very useful in certain places where files needed to be overwritten. Can we make that option visible in the manual?

https://github.com/nix-community/home-manager/commit/37694e9f5143ff64fdd201f02e37a68e6fc90288

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[ToasterUwU]

I ran into this issue as well now. Specifically with the .gtkrc-2.0 file, so "force" wasn't even an option. I used the home manager gtk option to set a theme and then kept getting that error over and over telling me to enable something I already have. All I had to do was delete the .gtkrc-2.0.backup file that already existed and was in the way, but this should not be necessary in the first place.

[ToasterUwU]

I global option for either not making a backup of a file entirely or even better, an option to always overwrite a backup file with the new one if needed would solve this issue nicely, but currently im stuck in an endless loop of having to manually delete a single file, which really defeats the purpose of this whole system i made myself.

home-manager.overridebackupFiles might be a good name for this.

[ToasterUwU]

Seems like there was already an issue and a PR about this. But the person who made the fix for this couldn't get the approval of the maintainer.

Issue: #4566 PR: #4971

[OsiPog]

I'm having the problem decribed above with stylix. I have to change home-manager.backupFileExtension every time I reboot otherwise starting the home manager service fails.

Does anyone have a fix for this?

[ToasterUwU]

@OsiPog If you have a list of files that are the issue (for me its only one and always the same), you can make a cron job/systemd timer and service to delete the backup file of these files.

In my case, im about to do this. The idea is that every 5 seconds, i check if "/home/aki/.gtkrc-2.0.backup" exists, and if so delete it. That way, i will at least have a low chance of the file being in the way, not 0 sadly.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixos-rebuild-fails-on-backup-up-config-file-by-home-manager/45992/2

[jezcope]

I run into this regularly with ~/.config/mimeapps.list after setting xdg.mimeApps.enable = true: there is one desktop app (it's an Electron-based app, of course...) that aggressively adds itself to this file by making a copy, inserting a line and then moving the copy into place, replacing the (read-only) store symlink. First time this happens, no problem, hm backs up the file as intended; second time my hm activation starts to fail until I manually remove the file, its backup or both.

[OsiPog]

To anyone encountering this problem. I solved the issue for me by adding a command that deletes all these backups at the start of my rebuild script (I'm using a fish function for that but it could also just be a writeShellBin):

# Delete all backup files
find ~ -type f -name "*.homeManagerBackupFileExtension" -delete

# ...

and specified in my configuration:

  home-manager = {
    # ...
    # files with this extension should be deleted regulary 
    backupFileExtension = "homeManagerBackupFileExtension";
  };

That is most likely against the idea behind that backup feature but that workaround works really well for me.

[different-name]

@OsiPog, @ToasterUwU for a purely nix config solution, you can do this using system.userActivationScripts instead

Configuration example for @ToasterUwU's /home/aki/.gtkrc-2.0.backup

[!Warning] Always be mindful of what you are removing and make backups of any files you are removing before you have verified your configuration is working as intended. Triple check for typos!

system.userActivationScripts = {
  removeConflictingFiles = {
    text = ''
      rm -f /home/aki/.gtkrc-2.0.backup
    '';
  };
};

If you are only removing single files as shown above, and not all backup files as @OsiPog suggested, then justloveinger's solution of using home.file."foo/bar".force = true; is far cleaner.

Unfortunately I haven't been able to get the force option working yet, most likely due to another module with conflicting definitions. The error message is not very helpful for working out where this is coming from

error:
Failed assertions:
- different profile: Conflicting managed target files: .gtkrc-2.0

This may happen, for example, if you have a configuration similar to

    home.file = {
      conflict1 = { source = ./foo.nix; target = "baz"; };
      conflict2 = { source = ./bar.nix; target = "baz"; };

Until I figure out what's causing that issue, using system.userActivationScripts at least allows me to rebuild

I'm using an ephemeral home set up, as such it makes no sense for me to keep backups of any of these configuration files written to by home manager. Would love to see progress on #4971, but seems to have reached a dead end

[justinlovinger]

Unfortunately I haven't been able to get the force option working yet

Try home.file."foo/bar".force = lib.mkForce true;.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/flake-homemanager-backup/49043/4