[aspect-devel] mktemp failure

[Timo Heister]

>> When I directly call
>> mktemp from the submission script it seems to work fine, so maybe the
>> forked child process is not inheriting the correct permissions?  Does
>> anyone have an idea why this would happen?
>
> No :-(

We could make the "write to temp and copy" part optional. A quick fix
to try out would be to set "Number of grouped files" to 1 in the
Visualization part of the prm. Does that work on this cluster, Eric?

>> Also, is there a particular reason why Aspect forks a process to call
>> mktemp instead of just calling mkstemp in the standard C library?
>
> I was looking for a function that (i) isn't marked as "do not use, ever,
> since it is a security risk", (ii) does not create a race condition when
> running in parallel on the same machine. All functions that generate a
> file name but don't actually open the file violate (ii). Pretty much any
> other function violates (i).

>I think mkstemp could work (I don't know
> why I didn't find that). I'm not enough of a C programmer to know what
> it means that the function returns an 'int' -- is that the same as
> FILE*? And how do I convert it to a C++ std::ostream?

Let me quote yourself, Wolfgang:
> The only one one should use is mkstemp
> but this function creates a file handle that points to a file that
> is destroyed upon closing the file handle. How am I supposed to
> copy this file around then if it gets deleted right away?

-- 
Timo Heister
http://www.math.tamu.edu/~heister/