A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

Using the example from the article, extracting an archive. Surely that use case is entity not possible using in-memory? What happens if you're dealing with a not-unreasonable 100gb archive?

Who runs around with 100gb+ of swap?!

Who runs around with a 100gb+ /tmp partition?

Our default server images come with a 4.4GB /tmp partition...

I run a script that rotates my /tmp/ each day, so I can access yesterday's tmp files at /tmp/20250828/ and so on.

My /tmp is my default folder for downloads and temporary work. It will grow 100GB+ easily.

Sure, but note that your usecase goes specifically against fhs and posix specs:

>Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

>Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.htm...

Now you can obviously use your Filesystem whichever way you like, but I would say Debian shouldn't have to take into consideration uses which are outside the general recommendations/specs.

Your use case sounds more like "scratch" folder, not really what /tmp is meant for.

This reminded me of the spacebar heating xkcd: https://xkcd.com/1172/

(not making fun of the workflow or anything, it's just that changes like tmpfs breaking stuff very much holds true)

Use `/var/tmp` of you want a disk backed tmp. Not sure why the article omits that.

For a long time my default download folder was /dev/shm. It is / was? the memory tmpfs and everything would just be gone after a reboot. Now I can just use /tmp

Even used something similar on my windows pc, had a B:/ disk 1GB in size that was my download folder. Automated cleanup made easy.

Programs shouldn't assume that about /tmp, the user advising this is fine.

And even your use case will benefit from any change, since you'll just move to /tmp2 instead of /tmp, which will actually behave you want it to.

So 99.9% of the users + you benefit from the change. I'm sure there are people that really rely on unconventional usages, but they are silent atm.

And so you now have to make a decision, is this file small or large? This pushes the problem to users and programs. (A very real problem too, we made large changes throughout libguestfs to sort out "small" and "large" files and put them into /tmp or /var/tmp. Entirely unnecessary if /tmp wasn't tmpfs on some systems).

The user wasn't "advising" this, or asking if it was fine. They're just doing it. Everything that they want to do with their own computer is permissible.

The person you're replying to is saying that tmp is meant for temporary storage that could disappear between reboots. A permanent archive of the past states of the tmp directory is not temporary.

/var/tmp is not allowed if you wish to pass security audits, it MUST be a bind mount to /tmp

I meant from the perspective of the program. You can't assume /tmp to be stable, but when the user tells you it's fine, then it is fine.

> A permanent archive of the past states of the tmp directory is not temporary.

From the perspective of a program it's still volatile, since the files don't stay in their original place.

What is the rational behind requiring it being a bind mount (or also whatever other options are allowed)?