Reminder to clear your ~/.cache folder every now and then

You don't have to clean your ~/.cache every now and then. You have to figure out which program eats so much space there, ensure that it is not misconfigured and file a bugreport.
- So OP's headline should be saying instead: Reminder to CHECK your ~/.cache folder every now and then
  
  just symlink ~/.cache to /dev/null
  
  Check? Why?
  
  % du -sh ~/.cache 1,6G /home/bizdelnick/.cache
  I don't remember if I ever cleaned it up. Probably a couple years ago when I moved my old HDD to new PC with freshly installed OS. It does not grow accidentally. Only in some very rare cases. As well as some other dirs under ~ and var. If it is a critical system, set up monitoring of free filesystem space. If not, you will notice if it becomes full (I can't remember when this happened to me last time, maybe ~15 years ago when some log file started to grow because of endless error messages).

That’s not very cache money of you

I did this and now my games have no icons in lutris, some of my gnome settings got reset and my proton email bridge stopped working
- So the apps are broken. Cache is meant to be deleted at any time
  
  not necessarily during runtime
- For some reason devs can't wrap their head around cache being temporary.
- You shouldn't have done that Dave.
- Cannot this be caused by deleting the folder and not just everything inside?
  
  It's likely. mkdir fails to create a subdirectory such as ~/.cache/mozilla/ if ~/.cache/ doesn't exist, unless -p is explicitly passed to mkdir
  Of course, not everything is a shell script, but I imagine the directory creation functions in many languages work similarly
  
  The contents were deleted

Even better: mount ~/.cache as ramfs. It will also speed up some apps significantly.
- I always felt that there should be some user directory like /tmp/ which will be wiped regularly.
  
  /run/ contains such a directory
  
  /tmp and /var/tmp are writable to regular users on most distributions

Because of excessive RAM I symlink ~/.cache to /tmp. Additionally installing zramswap helps for this scenario.
Benefits are faster access, automatc purging between reboots and no wear to the NMVe drive.
Yes, this is a single user scenario.
- Isn't most of what's in there just filters downloaded from the internet? Python packages, browser cache, etc? Your system confirms you to redownloading everything all the time, no?
- This seems like a filename conflict waiting to happen. Why not just mount a tmpfs there?
  
  Like I said it's a cheap solution for a single user system. Ofc tmpfs would be better but has to be done for every user again
- Once I get more than 16GB of ram I'll definitely try that
- Thats not very secure. /tmp/ is usually 777

I don't think I've ever seen .cache get bigger than 10GB
- It looks like yay was storing AUR build files there, that folder took up about 160 of the 164GiB
  
  You can use yay -Sc to clean the cache. It'll also ask you if you want to clean the pacman cache, which I'm assuming you also haven't cleaned (check the size of /var/cache/pacman).
  
  You should try using paru, might be better off with it.
  
  If it is true, it is a bug in yay. Cashe should not grow without limit.
  
  Shouldn't it store that stuff in data-home or state-home? Pikaur compiles in cache and stores it in data-home after.
- Depends on the distributions and default settings. In arch, by default, pacman doesn't delete cache.
  
  Pacman's cache isn't in ~/.cache though, it's in /var/cache. So whatever is taking up this much space isn't the package manager.
  That being said, I think the arch devs should add a config option to automatically delete old packages without having to run paccache manually and have it default to the last 2 versions of a package or so. It can grow quite big over time.

Your Distro should normally do that for you.
Advising for this means people will delete random cache and download stuff always.
Are multiple files in there? If yes you could add a script that only deletes files of certain age.
- I'm not aware of any distro that automatically clears a user's .cache in their home directories. Maybe you're thinking of /var/cache?

Question, could you have cron/crontab do it monthly or something? Do it monthly meaning delete everything in ~/.cache every month or so?
- [This comment has been deleted by an automated system]
  
  This is the good shit I miss from reddit. Thank you for posting a systemd service config, I'm going to implement this.
  
  Thanks for this! I've been meaning to start getting into learning more about systemd and making services, this is super detailed and gives me a pretty good starting point!
- Don't. You don't need to clean it unless cache of some buggy program grows uncontrollable.
- You could have a cronjob run something like find /home/user/.cache -type f -atime +30 -delete, which would find files that haven't been accessed in the last 30 days and delete them. Make sure your home partition is not mounted with the noatime option though.
- I just found this today, I don't really know anything about cron jobs but this will probably incentive me to learn lol
  
  Did you happen to see which subdirectory was using up this much space? I don't think I've ever seen .cache go above 10GB, so this may be a bug in a piece of software you use.
- Just mount it into your RAM

No way. If i clean up my .cache directory my precious cached with sccache rust deps would be very upset. >:[

You can also setup a cron job to periodically clean oldest files for you.
Example: @weekly find ~/.cache -type f -mtime +7 -delete
This will delete everything older than 7 days inside your cache folder.
- I guess you could also Mount a tmpfs to that directory

Doesn’t Steam store the game library there?
- No, .cache is similar to a temporary directory (or at least in theory) where important data isn't supposed to be stored there, instead only temporary files that might speed things up (e.g. images in a browser or thumbnails in a file manager). In this case it looks like all of my AUR packages had their source files cached, which added up over the ~1.75 years that I've been running this distro
  
  Yep my bad! I mis-remembered .local/share/steam as . cache/share/steam. :)
- it stores it in ~/.steam
  
  Ah I was getting it confused. At one point Steam stored everything in ~/.local/share/steam and symlinked ~/.steam to it. Doesn't appear to be the case on Ubuntu 22.04, though I used to use Debian and grab the .deb from Valve's website. My bad! :)

seems like a bug in one of rhe programs you're using.
modt software automatically manages it's cache...
are you using build caching tools such as Mozilla sccache? These tend to create 20gb+ cache directories, especially if used with debug builds

....yeah let me go check that...
13,574 totaling 1.7gb, not too bad. Hey OP how do you get to this view? It looks like we both use nautilus but when I select "properties" on the .cache folder it looks different.
- the screenshot does not look like nautilus, maybe xfce?
- I use thunar (with ePapirus-Dark icons which is probably what makes it look like nautilus), I liked nautilus when I used it but thunar has a bit more functionality that I like
  
  Ah thanks!

NEVER

du -sh ~/.cache/* | sort -h
- ncdu ~/.cache/

Bleachbit is good for clearing up some space
- And deleting emails
  
  Even Hillery knows that one.
  Come on!
  /s

Check which folder is the biggest. I am going to go on a lim and say it probably is being caused by file roller
- It's yay, which took up ~160 GiB. It was storing previous versions of AUR binaries which I guess added up over time. I posted a screenshot of ncdu outputs for a more detailed breakdown in one of the other reply threads
  
  yay -Sc(c)
  Is probably a better command in this instance
  
  Honestly the reason I've put yay/paru's build directory into ram/tmpfs long ago. It's almost never worth it keeping all those packages checked out. You also do your ssd a favour by not hammering it with compile workloads.

Is it safe to clear ~/.cache/mozilla/ while Firefox is running?
- No.
- Maybe not while it's running, but .cache is intended to be temporary files only so expecting files to permanently be there should be treated as a bug

I just map both the user cache and the /tmp directory to a RAM drive. I allocated 4 GB but in practice it never gets even close to that much, and Linux seems to not be reserving the entire 4 GB at boot so I would assume how much RAM is used depends on how much is actually in your cache.
It also defers cache and tempfile related problems to turning it off and on again.

This particular folder caches many things from various package managers. Won't hurt to clear, but will fill up again. Maybe consider not using caches when engaging such things.
- Can hurt to clear, there's a lot more than just package managers using it
  
  It's a cache folder. Created by the distro. They labelled it as such because it's cache, and can be considered ephemeral. It won't do any permanent damage to anything unless you've accidentally been using it for something else.
- Package managers don't use this directory as well as any other subdirectory of user's home.
  
  Could have fooled me, because it's certainly the default for things like brew, flatpak, mpm, and pip. Looks like npm and maven use it on certain Debian based distros as well. I'm betting more of the immutable distros use that directory as well vs something in /var/cache.
- How?
  
  Depends on the package manager. Check options for whatever you're running.

$ crontab -e
*/2 * rm -rf /home/lntl/.cache

This is why Linux sucks!
- Windows famously never generates any garbage files. It's so reliable all servers run windows. Right?
- That's nice
- Like the kernel itself sucks or a specific distro sucks?
  
  Don't feed the trolls.
  
  ALL OF IT

This is one of those things that makes me shake my head about Linux. It's these small dumb problems that make Linux inaccessible to the common person.
- Yes because other operating systems never have any small annoying issues.
  
  They do have small annoying issues. This is not one of them. This is something that would completely baffle a non-tech literate person. They'd just observe their computer becoming slow or not having space and say "well, Linux must have broken my computer."
- I've never seen any of my ~/.cache directories get more than a few GB either and I never bother to clean them.
  I am curious what OP was doing that used that much space though. That's certainly not typical.
- Not really. I've never seen .cache get bigger than 10GB, which is about how big the temporary files in Windows get if you never clean them.
  
  It ended up being yay storing binaries from previous versions of AUR packages, definitely depends on the distro/usage but for arch-based it definitely clears up a lot of storage
- I've seen similar issues in appdata on windows when a program is poorly configured and simply grow its logs to ridiculous sizes. It's an issue with a program utilising that folder, not the os.
- Well, they're an Arch Linux user which is a special case. On Arch and derivatives it's the user's responsibility to manage the system so this doesn't happen, configure cleanup daemons, flush package managers, etc., alternatively it could also be a misbehaving application which would have to be reported. Arch is for hobbyists who likes to do this.
  On other Linux distributions, Windows or macOS if this happens it's usually an application not properly managing its cache.
- I've been running Linux as my primary OS since the late 90s and have never run into this problem.
- The hate you're getting for this is so revealing and depressing. It basically proves you right.
  To the haters: where is the factual problem with this personal opinion? Have you considered making a counter-argument instead, instead of simply lashing out with the downvote button like spoiled infants? This kind of tribal pile-on really pisses me off. You are literally censoring an opinion expressed in good faith - downvotes hide comments and reduce reputation. All while offering no rebuttal, no ideas of your own, nothing. Nice work.
  
  Not a "hater" in terms of trying/wanting to be mean, but I do disagree. I think a lot of people downvoting are frustrated because this attitude takes an issue in one application (yay), for one distro, and says "this is why Linux sucks / can't be used by normies". Clearly that's not true of this specific instance, especially given that yay is basically a developer tool. At best, "this is why yay sucks". (yay is an AUR helper - a tool to help you compile and install software that's completely unvetted - see the big red banner. Using the AUR is definitely one of those things that puts you well outside the realm of the "common person" already.)
  Maybe the more charitable interpretation is "these kinds of issues are what common users face", and that's a better argument (setting aside the fact that this specific instance isn't really part of that group). I think most people agree that there are stumbling blocks, and they want things to be easier for new users. But doom-y language like this, without concrete steps or ideas, doesn't feel particularly helpful. And it can be frustrating -- thus the downvotes.
  
  It is what it is. I've been involved in Linux communities long enough to know not to take stuff like this personally.
  On Reddit we saw constant posts about why Linux isn't more popular but no one ever talks about all the dumb little issues that the distros have because of a slight lack of polish. Those little issues make the distros seem cheap compared to the polish of something like Windows.
  I'm always amused at the replies I get with things like "When I had Windows it literally caused my CPU to burst in to flames and my SSD shot my dog. Now I'm running Arch and it showed me last night's winning lotto numbers."