Jim Lesurf writes:
Richard Kettlewell wrote:
If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

Is that something I can expect anyone who used my programs to either
already have, or be happy to setup?

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.

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don’t use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don’t care about the filename, the easiest policy is to use
tmpfile(). That’ll given you an anonymous file somewhere sensible.

If you do care about the filename, use mkstemp().

To expand on that: I just checked my (Mint) laptop and it does have a
tempfs set up for /run. And inside that I find, for example,
/run/usr/1000 directory that presumably for tempfiles associated with
things being run already for me as user 1000. I can create files, etc,
in that when operating as myself, so don't need to be root. Seems OK
for me.

/run isn’t really the right place for application temporary files.

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

On Fri, 22 May 2015 13:53:43 +0100, Richard Kettlewell
wrote:

Jim Lesurf writes:
Richard Kettlewell wrote:
If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

Is that something I can expect anyone who used my programs to either
already have, or be happy to setup?

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.

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don’t use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don’t care about the filename, the easiest policy is to use
tmpfile(). That’ll given you an anonymous file somewhere sensible.

If you do care about the filename, use mkstemp().

To expand on that: I just checked my (Mint) laptop and it does have a
tempfs set up for /run. And inside that I find, for example,
/run/usr/1000 directory that presumably for tempfiles associated with
things being run already for me as user 1000. I can create files, etc,
in that when operating as myself, so don't need to be root. Seems OK
for me.

/run isn’t really the right place for application temporary files.

I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

d

(Don Pearce) writes:
I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

Both are highly predictable values. If you’re not using O_EXCL then you
probably have a security vulnerability.

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

On Fri, 22 May 2015 14:26:17 +0100, Richard Kettlewell
wrote:

(Don Pearce) writes:
I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

Both are highly predictable values. If you’re not using O_EXCL then you
probably have a security vulnerability.

I wasn't really thinking of security - just avoiding a file name
collision.

d

In article , Don Pearce
wrote:
I don't know if it is the same in all OS, but for temp files I generally
use a word relevant to the programme plus the current process ID number.
This pretty much guarantees a unique name that won't be used by anyone
else.

I tend to do something similar for tempfiles in ram: when using RISC OS.

Security isn't really an issue there as RO doesn't have much anyway beyond
their only being one user! The only user is the root user. End of.

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

On Fri, 22 May 2015 13:53:43 +0100, Richard Kettlewell
wrote:

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

I would add to that, if it isn't set, set it as pointing to /tmp

As a possibly interesting aside which may help some users of embedded
devices, some programs / programming environments have a need or use
of TMPDIR, for example PERL, but this may not always be well
documented. One of the reasons for GetIPlayer or cpan update failing
on embedded devices can be either this variable is not set by the OEM
firmware's default boot up, or else it points to a very limited amount
of on-chip ram. The following sequence of actions in a user post-boot
script can resolve this difficulty, where hard-disk should be
replaced by the normal means of accessing the hard disk of the NAS or
media player in question:
1 if [ ! -d hard-disk/tmp ] ; then mkdir hard-disk/tmp; fi
2 cp -a /tmp/* hard-disk/tmp
3 mount --bind hard-disk/tmp /tmp
4 export TMPDIR=/tmp

In stage 1, you could also have an else statement that cleans out old
files.
--
================================================== ======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

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

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system() to
launch flac and have it put its output into a file which I specify by its
name. Then my main program uses that name to fopen() the file and read from
it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How would
I use that as part of the command string for flac?

I did find a man page for tmpname() but having given the details it says to
"Never use it!".

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

Jim Lesurf writes:
Richard Kettlewell wrote:
1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system() to
launch flac and have it put its output into a file which I specify by its
name. Then my main program uses that name to fopen() the file and read from
it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How would
I use that as part of the command string for flac?

“If you don't care about the filename� means exactly that. It sounds
like you do care about the filename.

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

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

"If you don't care about the filename" means exactly that. It sounds
like you do care about the filename.

I don't mind what filename is chosen. But I would need to know what it is,
once chosen. So it depends what you mean by "care". :-)

That said, on another level I don't care because I can just stick with my
existing approach. ;-

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

On Fri, 22 May 2015 14:57:59 +0100, Jim Lesurf wrote:

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

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system()
to launch flac and have it put its output into a file which I specify by
its name. Then my main program uses that name to fopen() the file and
read from it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How
would I use that as part of the command string for flac?

I did find a man page for tmpname() but having given the details it says
to "Never use it!".

There are a couple of other ways to do this:

1) use a script to run flac and pipe its output directly into
your program like this:

flac inputfile | yourprogram


Your program will use a loop to copy bytes from flac's stdout stream
into a temporary file created using something like:

#include stdio.h
...
FILE flacfile = tmpfile();

This is a nameless file which will vanish when you close it or exit
from the program. You'd fill it by reading stdin and after that you
can reposition to its start by calling rewind() and read through the
file as many times as you want.

2) you can do more or less the same as above by using the fork/exec/wait
sequence instead of system() and read flac's stdout into a nameless
file created with tmpfile().

Sources like the aforementioned 'Lion book' give good guidance on
using fork/exec/wait


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |