Flac and Audio CD Health Checks
 

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

Flac and Audio CD Health Checks
 

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

Flac and Audio CD Health Checks
 

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/

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
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.

These paths don’t identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

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.

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.

mkstemp fills in a template, so it gives a full path if you supply a
template that will give a full path. It doesn’t delete the file; that’s
for you to do when you’re finished with it.

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

Flac and Audio CD Health Checks
 

In article
wwv1ti8r5fm.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
These paths don't identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

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.

It seems a shame, though, given that RO makes this easy.

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

Flac and Audio CD Health Checks
 

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

Flac and Audio CD Health Checks
 

On 22/05/15 15:18, Jim Lesurf wrote:
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.

Do you really need to do it this way? It seems rather inefficient.
I would prefer to make use of pipes, and get flac to stream the output to stdout and the program to read it from stdin.

This would avoid the nasty mess of temporary files, and reduce the wear on any physical disk.

Flac and Audio CD Health Checks
 

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 |

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 16:55:20 +0100, Jim Lesurf
wrote:

In article
wwv1ti8r5fm.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueX f87AxnpFoA.invalid,
Richard Kettlewell wrote:
These paths don't identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

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.

It seems a shame, though, given that RO makes this easy.

Jim

Can you wear an SSD this way? As I understand it they have an internal
OS that is constantly shifting the data around anyway, and putting in
some more from outside really doesn't make a great deal of difference.

d

Flac and Audio CD Health Checks
 

In article , Nigel Wade
wrote:
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.

Do you really need to do it this way? It seems rather inefficient. I
would prefer to make use of pipes, and get flac to stream the output to
stdout and the program to read it from stdin.

It depends on the meaning of "need". I've done it this way because its the
way I've managed (so far) to understand well enough to get working. But I
appreciate it is messy and clumsy. Afraid I'm not a very good programmer,
so just go for what gives me the required coconut.

I've been aware of pipes, but have no idea how I might actually use them in
this situation. If I can understand it, I may change to it in future. cf
my reply to Martin on this...

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