2

Programs often store config files in the home directory usually in a hidden directory, often but not limited to sub-directories of ~/.config, ~/.local or ~/.gnome

After uninstalling the programs, the config-files are still kept (which usually is preferred).

Currently I look through the hidden directories of home from time to time, try to guess where the directories belong to, and delete them, if I'm not using the program anymore. But this is time-consuming and difficult/error-prone, because sometimes it's hard to guess, which program a directory belongs to. I wonder if there is tool or method that could help me here. (Similar to Bleachbit or CCleaner on Win, but afaik they don't have this functionality).

Is there an easy way to identify and remove orphaned config-directories of uninstalled software?

Edit: I'm using Arch and Ubuntu, but solutions for other distros would be interesting, too. The solution doesn't need to be a user friendly GUI-application (would be nice, though), a CLI command or script would work for me, too.

Improve this question
4
  • What system, what installation method was used. These usually have means of removing these files completely! Commented Dec 17, 2017 at 12:05
  • With or without UI? What distro? Commented Dec 26, 2024 at 0:05
  • 1
    @RafaelMori, I'm using Arch and Ubuntu. GUI or CLI, both would be fine for me. Commented Dec 27, 2024 at 9:27
  • You already try Bleachbit? It's amazing.. just like a CCleaner for linux. But i'll try a answer.. haha.. Commented Dec 31, 2024 at 4:33

4 Answers 4

Reset to default
0

First off, create a backup before changing anything.

Sometimes the config files are installed by your package manager, whichever you use, and you can query its database, but I wouldn't rely on that. For some distributions there may be tools like findcruft (now abandoned) for Gentoo.

I think your best chance is to find and remove the files that haven't been accessed for a longer period, but this is no guarantee that the package isn't installed but inactive. Bonus points for checking the candidates against the package manager in a script.

$ find /etc -atime +7

Be aware that not all file systems support the atime feature, or it may be switched off intentionally, e. g. for SSD drives. In this case you can't use this approach. Or you'll first have to switch atime on for a decent period to gather the access data in order to make reliable decisions. Read about the relatime option first, too.

$ mount /dev/sda3 on / type ext3 (rw,noatime,nodiratime,data=ordered)

What's left as an option is to do it manually, guessing the related package by name and content of the file, which is usually straightforward.

Improve this answer
0

If the system is Debian based, aptitude can find packages with orphaned config (often in /etc), eg:

aptitude search ~c

and delete them with:

aptitude purge ~c

Usually the package manager does not create files in home-directories. Homedir config files are usually created at first run.
I think the best method is keeping theme tracked with tools lik Git so you can know exactly when they where created.

Improve this answer
0

on an rpm based system like Redhat or Centos or Rocky,

easy way... somewhat...

  • use rpm -qa to list all installed rpms,
  • then for each rpm of what is currently installed do a rpm -ql on each
    • for example rpm -ql chrony will report /etc/chrony.conf among some ~40 other files making up that rpm
    • capture all the *.conf files from doing an rpm -ql on each rpm reported from rpm -qa and save into a single text file named {for example} valid_confs.txt.
  • run a find on your local directories that you would consider a place for any installed/removed software for which could possibly contain a .conf file
    • for any .conf files resulting from running find, do a simple cat <found .conf file> valid_confs.txt and if it is not found then you found an orphaned .conf file... more specifically a .conf file that does not directly match to installed software as rpm has it recorded for where it should be located; if the paths mismatch but it's of an installed rpm then that will be useful as well.
Improve this answer
0

For Debian-Based distro:

There is a package called deborphan package, maybe fit. The man tells this at first lines:

DESCRIPTION

Deborphan finds packages that have no packages depending on them. The default operation is to search within the libs, oldlibs and introspection sections to hunt down unused libraries.

If it is invoked with an optional list of packages, only the dependencies on those packages will be checked. The results are printed to stdout as if the option --show-deps had been given. Searching for specific packages will show the package, regardless of its priority. It is possible to specify -, to read a list of packages from standard input.

Or you can try this (CHECK DIRECTORIES AND FILES BEFORE REMOVING!):

#!/usr/bin/env bash # List of common config directories. Put yours or some you know in this list, separating with spaces.. declare -a config_dirs=(~/.config ~/.local ~/.gnome) # Trying to find orphaned directories for dir in "${config_dirs[@]}"; do find "$dir" -type d -name ".*" | while read -r orphaned_dir; do if ! grep -q "$orphaned_dir" /var/lib/dpkg/info/status; then echo "Orphaned: $orphaned_dir" read -p "Want to remove this directory? [y/N] " yn if [[ $yn == [Yy] ]]; then rm -rf "${orphaned_dir}" fi fi done done

Remember to validate before removing.

About "/var/lib/dpkg/info/status" file:

This file is used by dpkg and higher-level tools like apt to track the state of packages. It is crucial for the proper functioning of the package management system because it stores essential information about which packages are installed, their versions, dependencies, and more.

When you uninstall a package, the package is removed, but its configuration entries may remain, which is why the status file can still list packages that have been removed but whose configurations remain on the system.

For Arch-Based distros:

I think you can just do this and it will be enough:

sudo pacman -R $(pacman -Qdtq)

Hope this helps!

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.