In article
wwvlhggrcx4.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

A common configuration is for /tmp to be a tmpfs. People who don't make
it a tmpfs presumably don't care... Put another way there's a limit to
how much policy your program should be setting; rather, it should be
following the user's policy.

If I understand that correctly it sums up one of the reasons for my
problem.

Under RO I'm used to ram: being the standard place for "temporary files
held in ram". But with the Mint boxes I have the temp 'device' seems to be
in /run, not /tmp. And presumably the assigned 'directory name' will vary
from one distro to another.

The other side of the problem is that I need a file *name* to get flac to
save its results to a file. Then have that name to get a handle to read the
contents (and delete the file afterwards) in my main program.

I'm used to getting a handle from a name. But AIUI tmpfile() would then
need me to get a name from the handle.

WRT mkstemp() I'm not clear if it gives the full pathname of the file. And
I had the impression that the file might then vanish as soon as flac quit
after saving it when run by a system() call, so leaving nothing for me to
read with my main program.

I'm sure I'm misunderstanding some of this, but saying the above helps
explain why so far I've not used this route. Its far more messy than the
approach under RO! ... even if that is for 'good reasons' in other terms.

/run did at least give me a subdirecory with the user's ID number to keep
accidental clashes between users apart. But even there I can't be sure of
the relevant directory being /run, not /tmp or something else. Or can I be
sure TMPDIR will tell me?

So far it seems simpler to just use the inside of the application
directory. But alas that means reading and writing to the hard disc on
which it may be stored. Hence my initial questions about 'wear' and
bufferring.

That said, with RO I sometimes give users the choice by letting them
set a path for temp files. I could do that to let them choose, but
it would make user setup more complex.


Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html