The practical (Unix) problems with .cache and its friends
23 comments
·February 5, 2025Zopieux
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.
quotemstr
It's because of articles like this that computing is an inconsistent mess. When you make a technical proposal in public like this, it's your responsibility to ask yourself "What would it look like if everyone did this?". If the answer is "a personal kind of hell", don't make the proposal.
Varriount
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.
WhyNotHugo
Agreed. What op wants in this case, is for XDG_CACHE_HOME to default to ~/cache when unset.
The idea is quite reasonable: suddenly all tools that show disk usage will show this directory clearly and you can easily find what’s eating up you space with the same usual tools as always.
Macha
I think they'll find they're in the minority on that opinion, so they should just set XDG_CACHE_HOME, and maybe symlink ~/.cache to ~/cache for those programs that have just hardcoded ~/.cache
mystified5016
Are dot folders actually a problem? I have show hidden files turned on globally everywhere always. I don't really understand how people operate otherwise.
hiccuphippo
> 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.
jmclnx
To me, on OpenBSD that kind of breaks the purpose of unveil.
Firefox and chrome on OpenBSD is patched to use pledge and unveil. That restricts where these programs can read/write data. I would not want a program to have access to all cache data for every program.
To me, if you see dir cache, you can clear it. In fact, I have a cron job to clear cache data older than a week for Firefox. No issues doing this for many years.
lloeki
> I would not want a program to have access to all cache data for every program.
Then XDG_CACHE_DIR doesn't change anything?
The path is going to be $XDG_CACHE_DIR/$PROGRAM which is what would get allowed (and neighbour subdirs disallowed); no program would get to see the others' cache.
I just checked and I have a ~/.cache/firefox right there.
Having it at a single root point means it's trivial to make all cache ephemeral in any way one chooses.
yjftsjthsd-h
Can ex. Firefox not unveil($HOME/.cache/firefox) ? Or actually I'd prefer unveil($HOME/.cache/firefox/$PROFILE)
rererereferred
How do you know it's a cache dir and not configuration or something else? I don't say programs should have access to the cache directories of other programs just to their own inside ~/.cache.
jmclnx
If I see the name cache I hope it is cache :)
So far that has not failed me yet, maybe some day I will get burned.
ignoramous
> I'd expect the application itself to have a clear-cache option or for it to do it automatically from time to time.
Android has this. Though, the reason they included a "cache partition" back in the day was to make sure there was always enough space to download flash system.img over-the-air (as wiping clean the cache partition would provide enough room).
zahlman
> 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).
koakuma-chan
> 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 ~
yonatan8070
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.
klodolph
I get kinda pissed at any program that creates a visible directory.
deadlypointer
I really like ncdu, which helps interactively detect and delete big unused directories.
pasc1878
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.
dlachausse
Fun fact, hidden dot files were not designed, but were the result of an early UNIX bug that users and developers came to depend on…
http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_...
neilsimp1
Wow I disagree so much.
Use XDG dirs: https://wiki.archlinux.org/title/XDG_Base_Directory#User_dir...
dare944
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.
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.