On 29Feb2016 00:47, Alan Bawden <a...@csail.mit.edu> wrote:
Cameron Simpson <c...@zip.com.au> writes:
On 22Feb2016 12:34, Alan Bawden <a...@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 <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
