Re: tmpnam() not unique

On Tue, Oct 14, 2014 at 9:19 AM, McGovern, Sean
<Sean.McGovern@xxxxxxxxxxxx> wrote:

If 2 jobs use tmpnam() at the same timestamp moment, I *think* the same filename is returned (though I don't know how to test this scenario).

I haven't coded to handle this possibility, and end up with two jobs trying to create the same temporary IFS file.

If you genuinely want temporary files (and not just unique
identifiers, or long-term files), then you probably shouldn't be using
tmpnam() at all. It's intrinsically not a robust way to create
temporary files.

Requesting a unique name and then opening a file with that name should
not be two separate operations at the application level. In
principle, what you want is an *atomic* operation that both creates a
guaranteed brand-new file, and returns a handle to that file. This is
precisely what tmpfile() and mkstemp() were designed to do.

I don't know whether these are available on the i, but I would imagine
so. Scott Hanson definitely already mentioned tmpfile(). I also
don't know whether these are implemented in a sufficiently robust way
(so they are truly atomic); I've been able to find different opinions
on the Web. It definitely depends on the platform. But I would
expect that (1) if they are implemented at all on IBM i, they are at
least as robust on the i as on any other platform, and (2) tmpfile()
and mkstemp() are never *less* robust than calling tmpnam() and open()
yourself.

Now, if you have the choice of either mkstemp() or tmpfile(), I have
no idea which is better.

John Y.