Make a unique filesystem path, without creating the file

[Cameron Simpson]

On 29Feb2016 00:47, Alan Bawden <alan at csail.mit.edu> wrote:
>Cameron Simpson <cs at zip.com.au> writes:
>> On 22Feb2016 12:34, Alan Bawden <alan at csail.mit.edu> wrote:
>
>I have deleted the part of discussion where it seems that we must simply
>agree to disagree.  You think mktemp() is _way_ more dangerous that I
>do.

I certainly think the habit of using it is. And thus we're off into the realm 
of risk assessment I suppose, where one's value sets greatly affect the 
outcome. But there are concrete arguments to be made about risks.

To your other question...

[...]
>In fact, mkstemp() also performs that same generate-and-open loop, and of
>course it is careful to use os.O_EXCL along with os.O_CREAT when it
>opens the file.  So let me re-state my argument using mkstemp() instead:
>
>If the code I wrote in my original message is "unsafe" because some
>_other_ process might be using mktemp() badly and stumble over the same
>path, then the current implementation of tempfile.mkstemp() is also
>"unsafe" for exactly the same reason: some other process badly using
>mktemp() to create its own file might accidentally grab the same file.
>
>In other words, if that other process does:
>
>  path = mktemp()
>  tmpfp = open(path, "w")
>
>Then yes indeed, it might accidentally grab my fifo when I used my
>original code for making a temporary fifo.  But it might _also_ succeed
>in grabbing any temporary files I make using tempfile.mkstemp()!  So if
>you think what I wrote is "unsafe", it seems that you must conclude that
>the standard tempfile.mkstemp() is exactly as "unsafe".
>
>So is that what you think?

Yes and no?

You're quite right that a task using mkstemp is not safe against a task 
misusing mktemp.

_However_:

In a space where everyone uses mktemp, everyone is unsafe from collision.

In a space where everyone uses mkstemp, everyone is safe from collision.

So provided everyone "upgrades", safety is reliable without any added burden in 
program complexity.

Of course, that sidesteps the scenario where someone is using mktemp to obtain 
a pathname for a non-file, but I am of the opinion that in almost all such 
cases the programmer is better off using mkdtemp and making their non-file 
inside the temporary directory. Again, provided everyone "upgrades" to such a 
practice, safety is arranged.

Because of this, I think that _any_ use of mktemp invites risk of collision, 
and needs to be justified with a robust argument establishing that the problem 
cannot be solved with mkstemp or mkdtemp.

Your example was not such a case. Ben's is, in that (a) he needs a "valid" name 
and (b) he isn't going to make an actual filesystem object using the name 
obtained. As it happens it looks like the uuid generation functions from the 
stdlib may meet his needs, addressing his desire to do it simply with the 
stdlib instead of making his own wheel.

So I remain against mktemp without an outsandingly special use case.

Cheers,
Cameron Simpson <cs at zip.com.au>