The practical (Unix) problems with .cache and its friends

What an objectively terrible, counter-productive take on what is an otherwise simple and solved problem.

Use an appropriately named folder (hi Nvidia, I hate your ".nv") in XDG_CACHE_HOME like every well behaved program in the past decade and let the disk space utilities solve the visibility issue.

What software should be doing is using XDG_CACHE_HOME, if it is set (along with the other XDG environment variables). That way cache directories will be where the user expects.

> Dear everyone writing Unix programs that cache things in dot-directories (.cache, .local, etc): please don't. Create a non-dot directory for it.

If it doesn't live inside ~/.cache or ~/.program/cache then I won't know if I can delete it or not.

If you are not putting your cache in one of those folders, I'd expect the application itself to have a clear-cache option or for it to do it automatically from time to time.

I usually agree with the things that Chris writes but this isn't one of them.

For starters, ~/.cache was invented because everyone was doing their own thing and the previous situation was FAR worse.

I don't agree with eliminating the concept of dot directories in unix just because some people haven't learned about them yet.

And of course he acknowledges that their environment is unique.

What I would do: run a script to symlink '.cache' to 'cache' in entry users home dir. Then it's not hidden anymore.

I don't think that putting cache in .cache is bad, as long as everyone does it. But some programs (like VS Code and Chromium) decided that .config is a good place for their cache and local files, which I think is a bigger problem.

XDG_CACHE_HOME, as mentioned by numerous other posters, is a good remedy to deal with this kind of cached-artifacts-sprawl - but it does need a will to cooperate and care from the original software developer in the first place, which ain't a given.

So does another standard that I've come to appreciate in all software that supports it: CACHEDIR.TAG (https://github.com/LineageOS/charter/blob/main/device-suppor...) - I'm just here to spread the word! ;)

I get kinda pissed at any program that creates a visible directory.

If your users are not fluent enough in Linux/Unix tools and conventions to be able to figure out how large a single standardized dotfile in their home directory is, I really don’t think the problem is “application developers are following a well-known standard.”

Wow I disagree so much.

Use XDG dirs: https://wiki.archlinux.org/title/XDG_Base_Directory#User_dir...

"Dot" files are a terrible idea to begin with.

It began as a dirty hack in "ls", in order to skip displaying "." and "..", it looked only at the first character of a file name. Exact string comparison is costly, and early UNIX could not afford that price.

Then people noticed that other ".whatevers" will also be "hidden", unless "-a" is specified.

Then it snowballed into hell.

Both Plan 9 and OS X tried to fix it, with "~/lib" and "~/Library" respectively, but especially as the latter was and is a certified UNIX, there's no avoiding a hundred random dot files and directories. I try to delete stuff I know I won't need again but...

    $ uname
    Darwin
    $ ls -a | grep '^\.' | wc -l
      61

Twenty of those were important enough for me to put them in version control, the rest is random crap. Even Hammerspoon, a *native* Mac app that hooks itself deeply into the OS APIs, uses its own dot directory.

Advice for all programs: follow the XDG spec[1]. Advice for OS vendors: default them to something more reasonable; ~/Library sounds appealing since we already use ~/Desktop, ~/Downloads, and so on.

[1]: https://specifications.freedesktop.org/basedir-spec/latest/

Hidden files with . are just not a good design.

the `du -s *` really shows that.

I wish they showed by default and you added a term to hide them.

Apple does not help here as they used to use ~/Library/Caches for all but now with sandboxes each Container has its own Cache and the sirectory they are in sometimes has a random name not simply the app name.

> As noted by Haelwenn /элвэн/, a plain 'du' will find such dotfiles. The problem is that plain 'du' is more or less useless for most people; to really take advantage of it, you have to know the right trick (not just the -h argument but feeding it to sort to find things). How I think most people use 'du' to find space hogs is they start in their home directory with 'du -s ' (or maybe 'du -hs ') and then they look at whatever big things show up. This will completely miss things in dot-directories in normal usage.

I don't understand. `du` indeed finds the dotfiles (and dot-folders); and if their contents are large, then they'll be noticed by someone who "looks at whatever big things show up". It's not at all clear to me why I'd be using a combination like `du -s *`.

Besides, there are more ways to hide the data from yourself (e.g. symlinking your desktop from somewhere else).

That said, I have found `ncdu` invaluable for navigating through the results, swapping between different views etc.

> And on Linux desktops, I believe that common GUI file browsers will omit dot-directories by default and may not even have a particularly accessible option to change that (this is certainly the behavior of Cinnamon's 'Files' application and I can't imagine that GNOME is different, considering their attitude).

"Cinnamon's 'Files' application" is Nemo, wherein you can right-click on any window and check the "show hidden files" option in the context menu (admittedly a strange placement, since it's a global setting).

I'm not sure I agree with this. The `~/.cache` directory is a standard, and it's usually the first place I check when I suspect my disk usage is too high. I do most of my personal work on a 15-inch MacBook Air with 16 GB of memory but only a tiny 256 GB disk.

I agree that putting cache files in `~/.cargo/cache` is worse than using the global `~/.cache`, but imagine the chaos if everyone decided to add their cache directory directly under the home folder without putting a dot in front of it.

Also, I believe the XDG spec should be followed on both macOS and Linux. Doing it differently on Mac is just a pain.

Yeah, no. The author's suggestion is reminiscent of the way Windows apps tend to dump their icons and directories straight onto the Desktop. It creates a God-awful mess that effectively hides anything the user tries to put there.

Imagine what your home directory would look like if you did 'mv ${HOME}/.cache/* ${HOME}'. No thank you.

App developers should not clutter my home directory with visible application-specific subdirectories. That's a fast way to get your application kicked to the curb.

I aliased ls to ls -A ages ago. While of course this doesn't solve any specific problems, it keeps one much more aware of what all's floating around in your home directory dotfiles.

> It's my view that this is a mistake and that everyone should put their big caches in a clearly visible directory or directory hierarchy, one that people can actually find in practice.

ls -a ~

You can put `.cache` in RAM (reducing wear on your SSD), with a fixed size limit. If something tries to exceed that limit, you'll know:

    $ df ~/.cache
    Filesystem     1K-blocks  Used Available Use% Mounted on
    tmpfs             819200 66360    752840   9% /home/user/.cache

With the manner exposed by the most feature-full DEs, Iʼd expect setting default to ~/Cache (not ~/cache, the latter is for the userʼs discretion).

But, I tend to agree with the main articleʼs premise that without a special teaching for the issue most newcomers will lose the issue.

Well looks like everyone has already said what i came to say.

XDG for the win.

The problem isn't the standard, its all the applications that don't follow it.

I really like ncdu, which helps interactively detect and delete big unused directories.