Evicting the Squatters in Your Home Directory - Getting Rid of Browser Caches

The Internet Browser is the single most important program for today’s users, no matter what system; Linux, Windows, Android, MacOS X, you name it.

But no matter if you use Firefox, Chrome/Chromium, Opera, they all keep flooding your home directory with cruft that you never asked for; mostly ~/.configand ~/.cache. While I can understand (grudgingly) the need to store some site-specific data in ~/.config, I simply have zero tolerance for all that cruft in ~/.cache; I found myself with my home directory growing from ~900 MiB to 1.5 GiB because of all that stuff.

I don’t want it. I don’t need it. But cleaning that stuff up (manually or with a script) only helps until you start your browser again; and in no time at all, it dumps half the Internet into your home directory again.

And backing up the home directory has become a chore; no more a simple rsync -av call, no, you need to explicitly exclude all that browser cache garbage.

There must be a better approach to this!

Well, there is. With a little symlinking and making use of /tmp now being on tmpfs, i.e. a RAM disk, I managed to move that stuff into that self-emptying garbage bin; welcome to temporary housing until the next reboot.

sh@meteor:~> ls -l ~/.cache
lrwxrwxrwx 1 sh users 13 Jan  5 14:50 /work/home/sh/.cache -> /tmp/cache-sh

sh@meteor:~> df -Th /tmp/cache-sh
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  7.6G  694M  6.9G   9% /tmp

sh@meteor:~> du -hs /tmp/cache-sh
687M	/tmp/cache-sh

sh@meteor:~> 

Good riddance! Hope you’ll like that next reboot!

All this takes is a little script:

sh@meteor:~> cat $(which mv-cache-tmp)
#!/bin/bash
#
# Move ~/.cache to /tmp/$USER-cache (on tmpfs, i.e. a RAM disk)
#
# (c) 2025 Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
# License: GPL 2.1

OLD_CACHE=$HOME/.cache
TMP_CACHE=/tmp/cache-$USER

# This may contain several directories, separated by whitespace
EXTRA_CRUFT="$HOME/.config/WarThunder/.game_logs"
EXTRA_CRUFT="$EXTRA_CRUFT $HOME/.config/chromium"


function show_du()
{
    DIR=$1

    if [ -d $DIR ]; then
        if [ ! -L $DIR ]; then
            du -hs $DIR
        fi
    fi
}


# Create the base dir in /tmp

if [ ! -d $TMP_CACHE ]; then
    mkdir -v $TMP_CACHE
else
    du -hs $TMP_CACHE
fi


# Show disk usage of the old directories

show_du $OLD_CACHE

for CRUFT in $EXTRA_CRUFT; do
    show_du $CRUFT
done


# Move the cache dir to /tmp

rm -rf $OLD_CACHE
ln -sf $TMP_CACHE $OLD_CACHE
ls -ld $OLD_CACHE


# Move the other cruft dirs to /tmp/cruft/

for CRUFT in $EXTRA_CRUFT; do
    if [ -e $CRUFT ]; then
        DIR=$(basename $CRUFT)
        TARGET="$TMP_CACHE/cruft/$DIR"
        # echo "Moving $CRUFT -> $TARGET"
        mkdir -p $TARGET
        rm -rf $CRUFT
        ln -sf $TARGET $CRUFT
        ls -ld $CRUFT
    fi
done


# Show some results

echo
ls -ld $TMP_CACHE
echo
/bin/df -hT $TMP_CACHE
echo

I put this into the autostart of my Xfce4 session, so it runs for every graphical login.

I have been using this since early December now without noticing any bad side effects.

5 Likes

Brilliant, @shundhammer . What worries me more than the diskspace is this ( ~/.cache was deleted in Jan 2025 ):

knurpht@Lenovo-P16:~/.cache> ls -R ~/.cache | wc -l
445426
knurpht@Lenovo-P16:~/.cache> 

So towards 500K files in ~1 year. I will implement this script tomorrow. BTW, if we talk about KISS, this is a super example. Thanks a lot. ( /me bangs head against table for never thinking about this, despite of having the same annoyance ).

This had bugged me for a long time. Not only does this consume disk space in my home directory, it also makes certain operations pretty much impossible; such as searching in my home directory for a file with a modification time just a few minutes ago. That file that my browser just downloaded - but where to? If you try a find, you will get a gazillion results - most of them completely irrelevant, because it’s browser cache stuff.

This is the reason why I added bookmarks in my QDirStat, so I could revisit and manually empty those directories - after reviewing, of course - with QDirStat. Browser caches, image thumbnails, huge replay files from my favorite game (WTF?!) that accumulate.

No more. The RAM disk is their grave. :smile:

My home directory is mine again; with a few exceptions, nothing is ever perfect. YouTube web storage, my roaming Firefox profile - stuff like that. But I really don’t want to back up half the Internet in my home directory.

1 Like

pshaw, my ~/.cache is only 8.5GB =P

But seriously, that’s a nice “hack” I’m gonna play with it a bit.

I like it, going to play with it myself. 27G of junk in ~/.cache.

I’m wondering if this is going to help resolve an issue I’ve noticed recently in Chrome - sites showing old certificates that are no longer served up by the site.

I moved my Firefox and SeaMonkey caches to /tmp roughly a decade before moving /tmp to tmpfs, using about:config’s browser.cache.disk.parent_directory.

There’s one sub-directory that’s been historically notorious to produce odd browser behavior, named “GPUCache”. It’s down in the the users ~/.config sub-dir path. (and not just for some browsers… or ~/.var… for browsers installed with Discover).

Just search in these openSUSE forums for “GPUCache” and you’ll see numerous posts about it.

Here’s a Reply link I posted over 2 years ago that shows the command to execute to find the GPUCache sub-dirs, plus a command to execute to quickly remove those sub-dirs (those sub-dirs will be re-created at the next execution of the browser … use the rm command shown at your own risk :slight_smile: )

Interesting, but I don’t find it for any of my installed browsers, just for Calibre.

There’s actually a ton of cache directories under there, not just browsers. My Chrome cache is “only” about 5 GB of that 27 GB. The largest chunk is actually pip.

That is only covering a per-browser setting. Stefan’s script takes care of the whole ~/.cache which IMNSHO is way more elegant.

2 Likes

Maybe, but I think the user should probably look to see what’s there. In mine, for example, I see a blender cache, caches for various gnome apps (control-center, desktop-thumbnailer, photos, etc).

Some are pretty old, some not so much.

This might end up being a way to find apps that are inappropriately using that directory structure, but if someone is dependent on an app that is doing that, they might be at risk of losing data, so looking first is probably a good idea, just in case.

1 Like

Excluding is straight forward:

erlangen:~ # grep @/home /etc/fstab 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /home                   btrfs  subvol=/@/home                0  0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /home/karl/.cache       btrfs  subvol=/@/home/karl/.cache    0  0
erlangen:~ # 

Daily backups work like a charm:

erlangen:~ # journalctl -S 0:00 -u btrbk
Jan 10 05:39:30 erlangen systemd[1]: Starting btrbk backup of /...
Jan 10 05:39:41 erlangen btrbk[269191]: --------------------------------------------------------------------------------
Jan 10 05:39:41 erlangen btrbk[269191]: Backup Summary (btrbk command line client, version 0.33.0-dev)
Jan 10 05:39:41 erlangen btrbk[269191]:     Date:   Sat Jan 10 05:39:31 2026
Jan 10 05:39:41 erlangen btrbk[269191]:     Config: /etc/btrbk/btrbk.conf
Jan 10 05:39:41 erlangen btrbk[269191]: Legend:
Jan 10 05:39:41 erlangen btrbk[269191]:     ===  up-to-date subvolume (source snapshot)
Jan 10 05:39:41 erlangen btrbk[269191]:     +++  created subvolume (source snapshot)
Jan 10 05:39:41 erlangen btrbk[269191]:     ---  deleted subvolume
Jan 10 05:39:41 erlangen btrbk[269191]:     ***  received subvolume (non-incremental)
Jan 10 05:39:41 erlangen btrbk[269191]:     >>>  received subvolume (incremental)
Jan 10 05:39:41 erlangen btrbk[269191]: --------------------------------------------------------------------------------
Jan 10 05:39:41 erlangen btrbk[269191]: /
Jan 10 05:39:41 erlangen btrbk[269191]: +++ /Btrbk/btrbk_snapshots/Backup/ROOT.20260110T0539
Jan 10 05:39:41 erlangen btrbk[269191]: >>> /Backup/btrbk_snapshots/erlangen/ROOT.20260110T0539
Jan 10 05:39:41 erlangen btrbk[269191]: /home
Jan 10 05:39:41 erlangen btrbk[269191]: +++ /Btrbk/btrbk_snapshots/Backup/home.20260110T0539
Jan 10 05:39:41 erlangen btrbk[269191]: >>> /Backup/btrbk_snapshots/erlangen/home.20260110T0539
Jan 10 05:39:41 erlangen systemd[1]: btrbk.service: Deactivated successfully.
Jan 10 05:39:41 erlangen systemd[1]: Finished btrbk backup of /.
Jan 10 05:39:41 erlangen systemd[1]: btrbk.service: Consumed 7.361s CPU time.
erlangen:~ # 

I was mainly agreeing that cache has no business being mixed in with user data and complicating keeping quality backups, secondarily reminding that with FOSS we enjoy options, and pointing one out. I didn’t examine the script, and now that I’ve taken a look at it, I wonder why so much is needed instead of a simple symlink. I’m no programmer, old, not keen on changing what works, and know rather little about scripting.

1 Like

Well, everything else you saw in the longer script is just defensive padding: creating directories, printing disk usage, handling reruns safely, and optionally dealing with a few non-cache directories. Useful, but not essential to the idea. At its core, the script is creating the desired symlinks into a tmpfs-backed location.

You could inset the desired “cruft” symlinking into ~/.profile if you desired eg

# Firefox
rm -rf ~/.cache/mozilla
mkdir -p /tmp/cache-$USER/mozilla
ln -s /tmp/cache-$USER/mozilla ~/.cache/mozilla

# Chromium
rm -rf ~/.cache/chromium
mkdir -p /tmp/cache-$USER/chromium
ln -s /tmp/cache-$USER/chromium ~/.cache/chromium

That achieves the same end result with fewer moving parts, and may be more suitable if you prefer keeping things simple.

Decided to go all the way. I have removed the entire ~/.cache before, never found any downsides. I reduced the script to this below, ran it once to test, then put it in ~/.config/autostart.

knurpht@Lenovo-P16:~> cat bin/mv-cache.sh 
#!/bin/bash
#
# Move ~/.cache to /tmp/$USER-cache (on tmpfs, i.e. a RAM disk)
#
# (c) 2025 Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
# License: GPL 2.1

OLD_CACHE=$HOME/.cache
TMP_CACHE=/tmp/cache-$USER

# # This may contain several directories, separated by whitespace
# EXTRA_CRUFT="$HOME/.config/WarThunder/.game_logs"
# EXTRA_CRUFT="$EXTRA_CRUFT $HOME/.config/chromium"


# Create the base dir in /tmp

if [ ! -d $TMP_CACHE ]; then
    mkdir -v $TMP_CACHE
else
     echo "$TMP_CACHE already exist"
fi

# Move the cache dir to /tmp

rm -rf $OLD_CACHE
ln -sf $TMP_CACHE $OLD_CACHE
ls -ld $OLD_CACHE

knurpht@Lenovo-P16:~> 

It may be me, but I seem to see quite some diffence in loading (specifically electron-) apps, i.e. faster loading.

A huge handout to @shundhammer

1 Like

About reducing.
There is no need to have

rm -rf $OLD_CACHE

because you have the -f option in the following

ln -sf $TMP_CACHE $OLD_CACHE

(Stupid) question from me: where does the output to stdout go that is generated (and is it really needed)?

Yeah, I guess so indeed. @shundhammer , your thoughts?

Merely there for manual testing. But it could go indeed. Or be replaced by some redirection to a logfile in /tmp

This is mosty for debugging. It may also go to ~/.xsession-errors; not sure.

This may be a leftover from testing. I usually build these scripts piece by piece and check manually if it did the right thing.

The rm doesn’t hurt, though. And it emphasizes the point that I really, really want to get rid of that thing. :slight_smile:

“Emotional Programming” is the new thing. :rofl:

While I understand that this topic concerns all stuff in ~/.cache I will just mention that you can easily set Firefox (and probably other browsers) to delete its cached files when it is closed. That will probably take care of most of the problem.