It's not an oxymoron to have files which are temporary but not limited in scope to a single power cycle. For example, you could have a long-running process which you want to be able to resume if it's interrupted; /var/tmp would be an appropriate place for the state. The data is temporary because it will be deleted once the process is finished, but you wouldn't want it wiped out by a system reset. Generally /tmp is cleared at every reset, and is often a tmpfs mount, while files in /var/tmp are automatically cleaned up only when they reach a certain age.
Except that the FHS says that "data stored in /var/tmp is typically deleted in a site-specific manner", and as an application vendor you have no control over that site-specific clean frequency. On all my systems, /var/tmp is a symlink to /tmp and that has never caused any issue.
The FHS is not wrong; cleaning policies are indeed site-specific and files placed in any temp directory can in principle disappear at any time. (Though, in theory, it's not supposed to happen while the files are still "in use" by running programs.) Still, historically you could count on files in /var/tmp lasting longer than files in /tmp, including across reboots.
Nothing will immediately break because you linked /var/tmp to /tmp. Whether it causes issues depends on the programs that you (or your users) run and how they make use of /var/tmp. However, if someone did have to restart a long-running process from the beginning because recent state information in /var/tmp was not preserved across a reset, I would say that is a problem with the administration of the system and not the program that stored its state there.
Basically no one uses /var/tmp for anything (and nobody should either). World writable directories are a mistake and only continue to exist because apps assume they are available.
/tmp and friends are poorly named. They really should be /shared or /dmz or /freeforall or something.
* If you need service-specific tmp space use RuntimeDirectory or PrivateTmp if your app is hardcoded to /tmp.
* If you need service-specific persistent data that goes in /var/lib/your-app.
* If you need temp space for your user it's at /var/run/user/your-uid.
* If you need more than one user/service to share files but not everyone then god have mercy on your soul because all options are bad. There sure are a lot of them but none of them are at all satisfying.
> "Persistent Temp" is also an oxymoron.
It's not an oxymoron to have files which are temporary but not limited in scope to a single power cycle. For example, you could have a long-running process which you want to be able to resume if it's interrupted; /var/tmp would be an appropriate place for the state. The data is temporary because it will be deleted once the process is finished, but you wouldn't want it wiped out by a system reset. Generally /tmp is cleared at every reset, and is often a tmpfs mount, while files in /var/tmp are automatically cleaned up only when they reach a certain age.
Except that the FHS says that "data stored in /var/tmp is typically deleted in a site-specific manner", and as an application vendor you have no control over that site-specific clean frequency. On all my systems, /var/tmp is a symlink to /tmp and that has never caused any issue.
The FHS is not wrong; cleaning policies are indeed site-specific and files placed in any temp directory can in principle disappear at any time. (Though, in theory, it's not supposed to happen while the files are still "in use" by running programs.) Still, historically you could count on files in /var/tmp lasting longer than files in /tmp, including across reboots.
Nothing will immediately break because you linked /var/tmp to /tmp. Whether it causes issues depends on the programs that you (or your users) run and how they make use of /var/tmp. However, if someone did have to restart a long-running process from the beginning because recent state information in /var/tmp was not preserved across a reset, I would say that is a problem with the administration of the system and not the program that stored its state there.
Basically no one uses /var/tmp for anything (and nobody should either). World writable directories are a mistake and only continue to exist because apps assume they are available.
/tmp and friends are poorly named. They really should be /shared or /dmz or /freeforall or something.
* If you need service-specific tmp space use RuntimeDirectory or PrivateTmp if your app is hardcoded to /tmp.
* If you need service-specific persistent data that goes in /var/lib/your-app.
* If you need temp space for your user it's at /var/run/user/your-uid.
* If you need more than one user/service to share files but not everyone then god have mercy on your soul because all options are bad. There sure are a lot of them but none of them are at all satisfying.
> Basically no one uses /var/tmp for anything
Gentoo does, at least by default: https://wiki.gentoo.org/wiki//etc/portage/make.conf#PORTAGE_...