On Fri, Jul 17, 2020 at 07:13:04AM -0400, rhkra...@gmail.com wrote: > On Friday, July 17, 2020 04:45:00 AM Nicolas George wrote: > > Zenaan Harkness (12020-07-17): > > > And mount /tmp as ramdisk ftw. > > > > tmpfs is not a ramdisk. > > I'm not the op, but, in what sense do you say that?
People who stress out over that typically fall into two categories: 1) "I don't want my Secret data being written to hardware, because They might be able to read it!! And yes, my favorite color is a Secret. Everything I write is a Secret! You can't be reading this!!" 2) "My disk will DIE if I write to it more than 37 times, so I must prevent ALL hardware writes!!" This is in addition to the regular old anti-temp-filers: 3) "Temp files are evil and messy and I Do Not Like Them!! But it's OK to use sed -i even though that uses a temp file, because I don't have to see it. Yes, I do like the taste of sand. Why do you ask?" So, these people (especially the first two) get all worked up about temp files, and will do incredible contortions and backflips to try to avoid them. Often, this breaks their script. They may not even care about that. To some of these people, perceived cleanliness is more important than the correct behavior of their software. What they all forget is that *most* of the time, a temp file will never be written to hardware, even if the file system is ext4 or whatever, simply because the temp file is so short-lived. If the program opens the temp file, uses it, unlinks it and closes it, all within a very short span of time, the kernel will not have had time to flush the data to hardware. That said, if you're writing programs for an environment where you *know* a RAM-based file system should exist (like Debian with systemd, where you can use $XDG_RUNTIME_DIR), you should consider using that for your small temp files.
