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

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