←back to thread

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

(lowendbox.com)
150 points shaunpud | 9 comments | 29 Aug 25 02:39 UTC | HN request time: 0.001s | source | bottom
Show context
Incipient ◴[29 Aug 25 05:23 UTC] No.45060518[source]▶
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?!

replies(2): >>45060583 #>>45061038 #
perlgeek ◴[29 Aug 25 05:34 UTC] No.45060583[source]▶
Who runs around with a 100gb+ /tmp partition?

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

replies(1): >>45060779 #
1. wielebny ◴[29 Aug 25 06:14 UTC] No.45060779[source]▶
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.

replies(5): >>45060892 #>>45060901 #>>45061000 #>>45061761 #>>45062109 #
2. cycomanic ◴[29 Aug 25 06:33 UTC] No.45060892[source]▶
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.

replies(1): >>45061950 #
3. perlgeek ◴[29 Aug 25 06:34 UTC] No.45060901[source]▶
Your use case sounds more like "scratch" folder, not really what /tmp is meant for.
4. KronisLV ◴[29 Aug 25 06:49 UTC] No.45061000[source]▶
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)

5. Mashimo ◴[29 Aug 25 08:52 UTC] No.45061761[source]▶
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.

6. 1718627440 ◴[29 Aug 25 09:23 UTC] No.45061950[source]▶
Programs shouldn't assume that about /tmp, the user advising this is fine.
replies(1): >>45062597 #
7. bmacho ◴[29 Aug 25 09:50 UTC] No.45062109[source]▶
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.

8. pessimizer ◴[29 Aug 25 11:13 UTC] No.45062597{3}[source]▶
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.

replies(1): >>45063507 #
9. 1718627440 ◴[29 Aug 25 12:56 UTC] No.45063507{4}[source]▶
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.