Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #95831 > unrolled thread

Does mkstemp open files only if they don't already exist?

Started bySteven D'Aprano <steve@pearwood.info>
First post2015-09-02 00:45 +1000
Last post2015-09-01 19:09 +0200
Articles 3 — 3 participants

Back to article view | Back to comp.lang.python


Contents

  Does mkstemp open files only if they don't already exist? Steven D'Aprano <steve@pearwood.info> - 2015-09-02 00:45 +1000
    Re: Does mkstemp open files only if they don't already exist? Chris Angelico <rosuav@gmail.com> - 2015-09-02 00:57 +1000
    Re: Does mkstemp open files only if they don't already exist? Laura Creighton <lac@openend.se> - 2015-09-01 19:09 +0200

#95831 — Does mkstemp open files only if they don't already exist?

FromSteven D'Aprano <steve@pearwood.info>
Date2015-09-02 00:45 +1000
SubjectDoes mkstemp open files only if they don't already exist?
Message-ID<55e5b9ec$0$1649$c3e8da3$5496439d@news.astraweb.com>
I assume the answer is "Yes", but is it safe to expect that
tempfile.mkstemp() will only create a file that doesn't already exist? I
presume that there's no chance of it over-writing an existing file (say,
due to a race-condition).


-- 
Steven

[toc] | [next] | [standalone]


#95833

FromChris Angelico <rosuav@gmail.com>
Date2015-09-02 00:57 +1000
Message-ID<mailman.45.1441119467.23514.python-list@python.org>
In reply to#95831
On Wed, Sep 2, 2015 at 12:45 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> I assume the answer is "Yes", but is it safe to expect that
> tempfile.mkstemp() will only create a file that doesn't already exist? I
> presume that there's no chance of it over-writing an existing file (say,
> due to a race-condition).

It depends on OS support, but with that, yes, it is guaranteed to be
safe; the file is opened with an exclusivity flag. Check your system's
man pages for details, or here:

http://linux.die.net/man/3/open

O_EXCL|O_CREATE makes an "atomic file creation" operation which will
fail if another process is doing the same thing. I'm not sure how
mkstemp() handles that failure, but my guess/expectation is that it
would pick a different file name and try again.

ChrisA

[toc] | [prev] | [next] | [standalone]


#95838

FromLaura Creighton <lac@openend.se>
Date2015-09-01 19:09 +0200
Message-ID<mailman.48.1441127373.23514.python-list@python.org>
In reply to#95831
In a message of Wed, 02 Sep 2015 00:57:45 +1000, Chris Angelico writes:
>On Wed, Sep 2, 2015 at 12:45 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>> I assume the answer is "Yes", but is it safe to expect that
>> tempfile.mkstemp() will only create a file that doesn't already exist? I
>> presume that there's no chance of it over-writing an existing file (say,
>> due to a race-condition).
>
>It depends on OS support, but with that, yes, it is guaranteed to be
>safe; the file is opened with an exclusivity flag. Check your system's
>man pages for details, or here:
>
>http://linux.die.net/man/3/open
>
>O_EXCL|O_CREATE makes an "atomic file creation" operation which will
>fail if another process is doing the same thing. I'm not sure how
>mkstemp() handles that failure, but my guess/expectation is that it
>would pick a different file name and try again.
>
>ChrisA
>-- 
>https://mail.python.org/mailman/listinfo/python-list


I remember discussion on the mercurial mailing list about
somebody who had a problem with this in conjunction with a
virus scanner that really wanted to get in and do things
to the poor temp files.

see: https://selenic.com/pipermail/mercurial-devel/2009-February/010197.html

for a very, very long thread about it.

Apparantly, you can get windows to complain that you cannot create a
file because it already exists, and it doesn't go back and try this
again for you.

But at the time I found the discussion puzzling, as my thought
was 'why are these people using mkstemp directly, instead of
tempfile.NamedTemporaryFile which seems to be what they want.

But I found this thread looking for a different problem with a
mercurial repository that we had that was corrupted, a year or so
after the thread was written, so I didn't want to go back and ask them
about it _then_.

Then in the general excitement --"Your raid system is buggy!  It is
inserting sludge in your files!"  I forgot about this puzzlement.
Until now.

Laura

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web