Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #95831 > unrolled thread
| Started by | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| First post | 2015-09-02 00:45 +1000 |
| Last post | 2015-09-01 19:09 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to comp.lang.python
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
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-09-02 00:45 +1000 |
| Subject | Does 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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Laura Creighton <lac@openend.se> |
|---|---|
| Date | 2015-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