Alt Text

A screenshot of a file manager preview window for my ~/.cache folder, which takes up 164.3 GiB and has 246,049 files and 15,126 folders. The folder was first created about 1.75 years ago with my system

  • bizdelnick@lemmy.ml
    165·
    11 个月前

    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.

    • redd@discuss.tchncs.de
      25·
      11 个月前

      So OP’s headline should be saying instead: Reminder to CHECK your ~/.cache folder every now and then

      • bizdelnick@lemmy.ml
        2·
        11 个月前

        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).

        • redd@discuss.tchncs.de
          7·
          11 个月前

          Because some users experienced accidential grows like OP had 160 Gbyte. So general advice for linux users can be stated as: Check your ~/.cache every now and then

          Critical systems/servers shall better be monitored as you suggest.

          • bizdelnick@lemmy.ml
            5·
            11 个月前

            Some users experienced accidential growth of /var/log. Some users experienced accidential growth of /var/cache. Some users experienced accidential growth of /var/lib. Some users experienced accidential growth of ~/.xsession-errors. Shall I continue?

            Does every user need to begin his day checking all that places? No, he does not. It is waste of time. Such situations are extremely rare. If you are paranoid, check df to see if you have enough free space, and only if it unpredictably shrinked begin to ivestigate which directory has grown.

            • redd@discuss.tchncs.deEnglish
              3·
              11 个月前

              I don’t get your point. Why should somebody do this every day?

              As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder. So checking it from time to time is a good advice. If we all do this for a time, and create bug tickets for software which is not cleaning up. Then this problem will hopefully go away with future software releases.

              • bizdelnick@lemmy.ml
                1·
                11 个月前

                Why should somebody do this every day?

                Why should somebody do this ever?

                As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder.

                It is the first thread about overgrown ~/.cache directory I see since I use Linux (~16 years or so). But, as I wrote above, this sometimes (rarely) happens with log files and some other directories. Checking each of them is a waste of time, if not automated, checking just one or few of them makes sense only if you are testing some app and looking for files it creates.

  • ryannathans@aussie.zone
    80·
    11 个月前

    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

  • neonred@lemmy.world
    40·
    11 个月前

    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.

    • Daniel Quinn@lemmy.caEnglish
      11·
      11 个月前

      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?

    • glibg10b@lemmy.ml
      7·
      11 个月前

      This seems like a filename conflict waiting to happen. Why not just mount a tmpfs there?

      • neonred@lemmy.world
        3·
        11 个月前

        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

        • glibg10b@lemmy.ml
          2·
          11 个月前

          You: It’s a single user system
          Also you: Tmpfs would have to be done for every user

          And a /tmp/ symlink would have to be created for every user too, so I don’t get your point

          Tmpfs is just as easy as making a symlink, but without the filename conflicts between files in ~/.config/ and /tmp/. You just need to add a line to /etc/fstab

          • tslnox@reddthat.com
            2·
            11 个月前

            /usr/local/sbin/adduser.local

            One line in there and you can make it add a new line with appropriate /home/userX/.cache tmpfs line to fstab.

            Or, maybe a cleaner way, you might make a init/systemd service that, when booting, would run something like

            for each dir in /home do
            mount dir/.tmp -type tmpfs
            done

            I’m not at the computer now and I’m lazy to Google it, so this above is just a pseudo code and probably won’t run.

            • glibg10b@lemmy.ml
              3·
              11 个月前

              Neat, thanks for sharing

              Here’s the above pseudocode in bash:

              find /home/ -mindepth 1 -maxdepth 1 -type d -exec mount none {}/.cache/ -t tmpfs -o size=16G \;

              for doesn’t work here because it uses spaces to delimit strings, which could cause issues with filenames that contain spaces

              You can also create a systemd user service, which is useful if you don’t have root access. The above mount command requires root, but the following doesn’t and is more robust than symlinking to /tmp/:

              ln -s $(mktemp -dp /var/tmp/) ~/.config/
    • Zangoose@lemmy.worldOPEnglish
      29·
      11 个月前

      It looks like yay was storing AUR build files there, that folder took up about 160 of the 164GiB

      • SuperIce@lemmy.worldEnglish
        21·
        11 个月前

        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).

        • 30p87@feddit.de
          1·
          11 个月前

          One would just need to modify the pacman cache hook for yay. I’m too lazy tho.

        • EddyBot@feddit.de
          1·
          11 个月前

          it doesn’t matter if you use paru, yay or heck makepkg if you are compiling packages with hilariously large sources like for example webbrowser (librewolf, brave, ungoogled-chromium, firedragon take each like ~30 GB) without pruning the build cache afterwards

          • Zangoose@lemmy.worldOPEnglish
            2·
            11 个月前

            Something I noticed was that in this case it was mostly binary AUR programs taking up the space.

            I think maybe since yay/AUR use cloned git repos, and old versions of binaries get stored in the git diff and then add up because different versions of the binary are basically like keeping multiple copies of it instead of just the changes to the source code.

          • brakenium@lemm.ee
            2·
            11 个月前

            My update script handles mirrors, updates and cleans the cache automatically. I’d definitely recommend creating one. It’s aliased to sysupdate for me and I also check if it’s a debian or arch based distro so the command works on my servers and desktop

              • brakenium@lemm.ee
                2·
                11 个月前

                I’ve heard of tools like that, but this works fine for me. This way I’m not dependent on it being packaged for my distro and having to install it through other means. I’m fine running things manually, this is just for convenience

      • MonkderZweite@feddit.ch
        2·
        11 个月前

        Shouldn’t it store that stuff in data-home or state-home? Pikaur compiles in cache and stores it in data-home after.

    • SkyeStarfall
      5·
      11 个月前

      Depends on the distributions and default settings. In arch, by default, pacman doesn’t delete cache.

      • SuperIce@lemmy.worldEnglish
        13·
        11 个月前

        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.

  • Pantherina@feddit.de
    22·
    11 个月前

    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.

    • Takios@feddit.de
      2·
      11 个月前

      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?

  • Dog@lemmy.worldEnglish
    18·
    11 个月前

    Question, could you have cron/crontab do it monthly or something? Do it monthly meaning delete everything in ~/.cache every month or so?

      • Zangoose@lemmy.worldOPEnglish
        4·
        11 个月前

        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!

    • bizdelnick@lemmy.ml
      4·
      11 个月前

      Don’t. You don’t need to clean it unless cache of some buggy program grows uncontrollable.

    • cmnybo@discuss.tchncs.deEnglish
      3·
      11 个月前

      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.

    • Zangoose@lemmy.worldOPEnglish
      3·
      11 个月前

      I just found this today, I don’t really know anything about cron jobs but this will probably incentive me to learn lol

      • SuperIce@lemmy.worldEnglish
        10·
        11 个月前

        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.

          • Zangoose@lemmy.worldOPEnglish
            5·
            11 个月前

            Looks like yay is storing every previous binary for AUR bin packages (also excuse the unreadable terminal theme, it doesn’t play very well with a lot of TUI apps unless they support custom theming)

            • Bronco1676@lemmy.ml
              2·
              11 个月前

              You should run yay -Sc from time to time. This cleans a) your pacman cache (which is normally done by executing pacman -Sc) b) your AUR build cache, which is what’s taking up 160GB. But this one seems rather unusual, I use paru (which also has the command paru -Sc), so I can’t really tell if this is normal with yay.

              The command also asks you for every directory if you want to delete it or not, so it’s completely save to run that command.

              • Zangoose@lemmy.worldOPEnglish
                2·
                11 个月前

                Something I noticed was that it was mostly the binary packages that were taking up so much space, it may be because of how yay stores the programs (does it use git?), the ones that were compiled from source code usually took up the least amount of space, while the binary programs were the ones taking up tens of gigabytes

                • Bronco1676@lemmy.ml
                  1·
                  11 个月前

                  Indeed, yay utilizes the AUR, which essentially serves as a Git repository for each package. These repositories typically include a PKGBUILD file and a .SRCINFO file, along with possible additional files like patches, desktop, or service files.

                  For example, take a look at IntelliJ Ultimate: [https://aur.archlinux.org/cgit/aur.git/tree/?h=intellij-idea-ultimate-edition]. It contains the .SRCINFO and PKGBUILD, as well as a .desktop file. These files themselves do not occupy much space.

                  The PKGBUILD specifies the sources for dependencies. For instance:

                  source=("https://download.jetbrains.com/idea/ideaIU-$pkgver.tar.gz"
        "jetbrains-idea.desktop")

                  The PKGBUILD is essentially a Bash script with predefined functions and variables. You can learn more about it here: [https://wiki.archlinux.org/title/PKGBUILD].

                  This script primarily downloads and extracts the tar file. In this specific case, it only relocates the files to their intended installation locations, like moving the desktop file to /usr/share/applications.

                  With such packages, there’s a possibility of wasting significant space since the tar file is downloaded and possibly retained in the cache.

                  However, other packages, especially those compiled from source, usually involve Git clones. These clones bring the Git repository into a subdirectory of the already cloned AUR package Git repo. Some might also have source tarballs. These types of packages generally do not consume much space in the cache, as they are often just text files, like C source code or Python scripts. These packages frequently rely on external libraries and packages, which are not included in this package’s cache.

                  While binary packages often bundle all necessary libraries and other components in their source tarballs.

                  The AUR cache is mostly beneficial if you’re rebuilding the same version or can reuse components from a previous version. For example, a package might depend on a large, static file that doesn’t change often.

                  In Paru, I’ve enabled the “CleanAfter” option to prevent my cache from overflowing. Given my relatively fast internet speed, redownloading large files isn’t a major concern for me.

            • neonred@lemmy.world
              2·
              11 个月前

              Wow, I’ve never seen something like this.

              Is it" allowed"? I mean, there are quotas for user homes.

  • majestic@sh.itjust.works
    17·
    11 个月前

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

  • noroute@lemmy.world
    14·
    11 个月前

    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.

    • Zangoose@lemmy.worldOPEnglish
      11·
      11 个月前

      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

      • conorab@lemmy.conorab.com
        1·
        11 个月前

        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! :)

  • voxel@sopuli.xyz
    9·
    11 个月前

    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

  • just_another_person@lemmy.world
    7·
    11 个月前

    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.

    • bizdelnick@lemmy.ml
      3·
      11 个月前

      Package managers don’t use this directory as well as any other subdirectory of user’s home.

      • just_another_person@lemmy.world
        1·
        11 个月前

        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.

      • just_another_person@lemmy.world
        4·
        11 个月前

        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.

  • Jinn@sh.itjust.works
    7·
    11 个月前

    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.

      • Jinn@sh.itjust.works
        4·
        11 个月前

        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.”

        • d3Xt3r@lemmy.nzM
          33·
          11 个月前

          FYI, Windows doesn’t have any feature either to automatically clear all of it’s temp folders (%TMP%, C:\Windows\Temp, C:\Windows\Panther), plus several other folders where orphaned files are often leftover, such as C:\Windows\Installer, C:\Windows\CSC, and various folders and cache files in your AppData\Local etc, to name a few off the top of my head.

          I used to be a Windows sysadmin for a long time, and let me tell you, HDDs becoming completely full due to cache/temp files is very much a problem in Windows.

          • Astaroth@lemm.ee
            2·
            11 个月前

            Guess what I found in /home/{user}/.wine/drive_c/users/{user}/Temp, 10GB of log files. Although 9GB was from one time when I used Cheat Engine and I don’t know what really happened tbh besides it causing a OOM crash.

            It created a 9GB sized file called ADDRESSES.TMP, I never considered checking for temp files in .wine before. And I guess I should be checking all the prefixes created by Steam games as well…

        • atzanteol@sh.itjust.works
          18·
          11 个月前

          Oh yeah, you never hear such complaints about Windows or MacOS.

          BTW can you recommend any good tools to cleanup my registry?

        • fluffyb@lemmy.fluffyb.net
          12·
          11 个月前

          I once had a huge 20ish GB file in windows I could not get rid of, move, or delete. It was related to hibernation or something like that… Even though I had hibernation disabled and no amount of googling could get rid of the file.

          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, my computer just broke itself better throw it in the trash and get a new one”

      • cmnybo@discuss.tchncs.deEnglish
        7·
        11 个月前

        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.

        • Zangoose@lemmy.worldOPEnglish
          4·
          11 个月前

          It was AUR packages from yay. I’m a CS major into gaming and emulation so there are a decent amount of programming build tools from the aur that I had, it looks like most of it is coming from storing all of the binaries from AUR packages, as intelliJ ultimate takes up 50 GiB, proton-ge-custom takes up 31 GiB, and Yuzu emulator takes up 16 GiB.

        • aleq@lemmy.world
          1·
          11 个月前

          I get the same all the time. OP reminded me to check today and Jetbrains toolbox had cached a lot of downloads that took up 42 GB in total. yarn folder with 2.3 GB. bazel folder with 15 GB (apparently used for building Anki),7 GB paru clones.

          All in all it added up to 82 GB.

    • SuperIce@lemmy.worldEnglish
      13·
      11 个月前

      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.

      • Zangoose@lemmy.worldOPEnglish
        2·
        11 个月前

        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

    • UndercoverUlrikHD@programming.dev
      11·
      11 个月前

      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.

    • JubilantJaguar@lemmy.world
      4·
      11 个月前

      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.

      • Jinn@sh.itjust.works
        3·
        11 个月前

        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.”

        • JubilantJaguar@lemmy.world
          2·
          11 个月前

          Ha! Yes I agree completely with all of that.

          And with your point here. In this world of pocket touchscreens and voice AIs, where young people don’t even know what a file is any more, the geeks here are reminding each other to empty their .cache directory from time to time. I mean, do they have no self-awareness? Or perhaps they simply don’t care if nobody chooses to use Linux. That at least would be coherent, but if there are no new users then eventually the whole thing will just die.

          • Zangoose@lemmy.worldOPEnglish
            1·
            11 个月前

            IMO I’d say the same thing about windows’s “Temp” folder though.

            I agree that a lot of Linux isn’t user friendly but I’m also on a distro that is specifically supposed to be customized from the ground up (arch-based) using a tiling window manager which also involves configuring most things from the ground up. This isn’t a problem that most Linux users will likely have, but it is a problem that people may have if they are power users trying to have full control over their system (people who will be on a community about Linux). From what others in this thread have been saying, non-arch distros (and even arch with other aur helpers than yay) tend to have much smaller caches that get up to around 10Gb at most, which is also similar in size to what Windows’s temp directory uses.

            This is a Linux community on a FOSS platform. This community is inherently going to be filled with more “geeky” people. Isn’t this what we signed up for? You make it seem like Linux was ever attracting people who weren’t these type of people to begin with. Computer science is still a growing field, and most sane computer science curriculums involve using POSIX terminal commands and by extension linux at some point. I’m a zoomer and can confirm, we’re not all as hopeless as you think we are. Linux will be fine even ignoring all of its corporate and government backing. And for people who don’t even know what a file is, they probably won’t know what Linux is in the first place. Even if they somehow have a system preconfigured with linux, their Ubuntu or Linux Mint install will probably be clearing the cache for them.

            • JubilantJaguar@lemmy.world
              3·
              11 个月前

              Some good points here, I stand partially corrected.

              There are in fact 2 completely separate things that irk me. The biggest is the virtual lynching that is mass-downvoting. I’m sorry, I will never ever pardon the downvoting of opinions, I think it’s the illness of the social internet since the very beginning. See my many other recent comments for evidence of how strongly I feel about this.

              The other issue is the actual one at hand! You’re right that this cache folder business does not really concern most ordinary users, even on Ubuntu. But actually, if even we geeks need to tell each other to “remember to do X every now and then”, I have enough of an IT mind to think “Why do we need to remember anything?! The tool should do this job for us!” These are “babysitting” chores and IMO on a decent OS there should be zero babysitting, it should be set up once and then it should work forever, with any tweaking optional.

      • the_sisko@startrek.websiteEnglish
        3·
        11 个月前

        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.

        • JubilantJaguar@lemmy.world
          2·
          11 个月前

          Fair enough, tho personally I don’t see this “doom-y language” you see, I just see a slightly exasperated opinion expressed in good grammar and good faith.

          But personally I don’t downvote people for their opinions, ever, as a matter of principle. It’s literally a form of censorship, given that it hides the comments. It leads straight to a deadening groupthink where dissenters are scared to open their virtual mouths. It creates a general aura of negativity and intolerance that helps nobody at all. Downvoting, as it is used by most people here and on the R-site, is an absolute scourge. If anything makes me leave this community, it will be this.

    • ProtonBadger@kbin.social
      3·
      11 个月前

      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.

    • TheWoozy@lemmy.world
      1·
      11 个月前

      I’ve been running Linux as my primary OS since the late 90s and have never run into this problem.