Make a unique filesystem path, without creating the file
cs at zip.com.au
Mon Feb 29 01:38:35 EST 2016
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
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
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
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.
Cameron Simpson <cs at zip.com.au>
More information about the Python-list