The XDG base directory spec (https://specifications.freedesktop.org/basedir-spec/basedir-...) was supposed to solve all of this...
In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".
Small you say? The block size in that device is the size of the memory page: 4K by default. That's 8 times the very typical 512b for persistent storage.
I've been bitten many times when trying to start in-memory only VMs with a disk image that measured smaller than available memory only to run out of memory on boot :)
Let's say it's not really for small files. It's for few files. ;)
I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user.
A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it.
In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.
That's on them.
I use /tmp like this, because I'm lazy and don't want to have to mess with a directory I need to routinely clean up, but I know that if the computer crashes, it's gone. That's on me.
If you don't like this risk, you need to work in persistent storage.
/tmp is for programs' temporary files. Manually using it like this is abusing it. That's fine, it doesn't hurt anyone beside the user doing it, but they need to bear the consequences of doing it.
Which is literally what /var/tmp is and what the parent is advocating for.
However, clearing /tmp at boot is not the greatest technical choice. There's nothing really special about rebooting the system. The idea that files in /tmp are kept around for anywhere between minutes, hours, and days makes for bad policy which systemd-tmpfiles fixes quite elegantly. You shouldn't lose your temp file after 30 seconds because your machine lost power. You should be able to say "files created here are cleared after $short_time of inactivity."
IMO setting the expectation of 'wont survive a reboot' is more consistent. but even that fails with private tmp files that could be tied to ephemeral units
In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.
That being said, all my systems have /var/tmp as just a symlink to /tmp, regardless of what the FHS may have to say about it -- and it's cleaned weekly, not just on reboot.
[0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... is the current home, apparently
Or it's useful system behaviour.
To-MAY-to, to-MAH-to.
> […] should exist under a proper /var/{cache,lib} directory.
Are these directories available to regular users like the tmp dirs are?
Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do.
You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to.
Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.
The purpose of /var/tmp is temporary files that should survive a reboot. A potential example where that would make since is a partial download file. It is only needed temporarily but if a reboot happens while the download is in progress, you probably don't want to have to start over.
Also if /tmp is or might be a tmpfs, it is probably desirable to use /var/tmp for larger temporary files that don't fit in RAM.
/var was originally for network booting machines. / is read-only fileshare and /var is for user storage. /home -> /var/home too. It's campus wide workstations installation type of thing.
So, /var/tmp is kind of wrong, and so is /var/log/messages on a laptop, and besides the entire /var is useless on most systems. But it's not a huge waste of resources either, so it's left as it is along the rest of directories under / for years.
/var wasn't originally intended to be a system directory, it's just a variables directory. Almost by definition it's writable.
I have run (Sun) workstations off of NFS, including completely diskless ones. /var was often done on a per-workstation basis.
(I'm actually planning out a diskless HPC cluster that will be deployed in the coming months.)
Honestly, we should probably abandon the hope that we will ever get full universal adoption. It stinks even worse with the half-adoption state we are in now, with some apps writing to those directories and other apps not. If it wasn't for arch Linux folks trying to drive apps to adopt it more, I don't think it would be. Hell, default Debian/Ubuntu still doesn't set XDG_* directory ENVs by default (some flavors do), and some apps ignore the prescribed "if not set, use this default" nonsense in the spec and do what they have always done because it doesn't break compatibility for users.
Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user.
Let's move to containerizing most apps, putting everything in little jails so we don't have to deal with where they want to write to. They can have their own consistent and expected behaviors on their own island. Snapcraft, flatpack, or any of a bunch of other solutions are already available to solve this problem. Don't have to worry about what some app left behind or wrote to your system when it's all contained.
You are supposed to leave them unset if they match the defaults.
Programs ignoring the spec is another matter and should be fixed in those programs not by needlessly bloating the environment of every process with meaningless data.
Things like .git and .ssh not are not meaningless data even though they are not in ~/.config/ssh/ or ~/.local/shared/git.
It stinks about half as much as before.
> Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user.
Caches don't have to be backed up and can be deleted if you need space. Most people will want to back up configs. What other data should be backed up is a question different people will answer differently. And containers don't solve this.
Otherwise, you're directly heading for a nasty surprise at the worst moment.
n = 1, but, uh, this is one major reason I don't use Linux. It really bugs me.
Actually AppData can get a bit polluted too.
Typical of our society, we want to make everything someone else's problem.
I guess we deserve some of the SaaS enshittification and it's spending obesity ;-)
Yes, this.
> Typical of our society, we want to make everything someone else's problem.
I don't think that's a fair analogy.
It's more like moving junk from the living room to the attic. I'd prefer to have a clean living room and a messy attic.
> Yes, this.
Like "My Documents" (or "Documents" nowadays)? Now that's some dumping ground.
~/Library also isn't something that is used to be; it was good idea, but mostly ignored. Basically similar idea as XDG_(CONFIG|CACHE|DATA)_DIR.
What's worst, is that many projects ignore any effort to move them to XDG schema. They take the approach, that they always did it this way, it works, so why changing it.
Dot files in my homedir on Sonoma machine:
.CFUserTextEncoding
.DS_Store
.Trash/
.Xauthority
.amt
.android/
.anyconnect
.bash_history
.cache/
.cargo/
.config/
.cups/
.degit/
.deno/
.docker/
.eclipse/
.emacs.d/
.gitconfig
.gitignore_global
.grass7/
.hex/
.homeassistant/
.ipython/
.java.login.config
.jupyter/
.kube/
.lemminx/
.lesshst
.local/
.matplotlib/
.mix/
.mume/
.node/
.notable.json
.npm/
.nvm/
.oh-my-zsh/
.oracle_jre_usage/
.pip/
.profile
.psql_history
.python_history
.rest-client/
.rustup/
.sqitch/
.ssh/
.subversion/
.swiftpm/
.thumbnails/
.viminfo
.vscode/
.wget-hsts
.wine/
.yarn/
.yarnrc
.zcompdump
.zsh_history
.zsh_sessions/
.zshenv
.zshrc