Jim Lesurf writes:
Richard Kettlewell wrote:
If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

I don't understand your objection. As far as I can see you're choosing
to avoid even the possibility of a tmpfs, on the grounds that you might
not actually get it. Which seems like cutting off your users' noses to
spite their faces.

"Objection" perhaps isn't the correct word. My concern is about how to let
the user employ it given that the 'locations' they have for tempfs may
vary.

You’re looking at this completely wrong. People don’t have locations
for tmpfs. There’s no such concept. People have locations for
temporary files, and their own policies about how temporary files are
stored, based on their preferred tradeoffs between performance,
persistence, etc.

However I did this because /run/user/ followed by my user id number seemed
a reasonably directory choice given that 'df' shows me its a tempfs
location mount *on my system*.

It’s a terrible choice. /run is for pidfiles, sockets, etc. It happens
to be a tmpfs in some configurations but there’s no guarantee that this
will be true.

It’s not that long since /run didn’t even exist.

--
http://www.greenend.org.uk/rjk/